← Back to team overview

maria-developers team mailing list archive

Re: 8a84f5a40c1: MDEV-24176 Preparations

 

Hi, Aleksey!

On Dec 29, Aleksey Midenkov wrote:
> > > > > +  /*
> > > > > +     NOTE: came from TABLE::alias_name_used and this is only a hint! It works
> > > > > +     only in need_correct_ident() condition. On other cases it is FALSE even if
> > > > > +     table_name is alias! It cannot be TRUE in these cases, lots of spaghetti
> > > > > +     logic depends on that.
> > > >
> > > > could you elaborate on that?
> > I see that. What I mean was, can you show an example?
> > Say, a query that sets TABLE::alias_name_used incorrectly?
> > I wasn't able to find a test case for that.
> 
> That's the original test case of the task. It has alias_name_used
> false. Well, early I had more problems with that. Now I did the PoC
> fix again and I see no big problems with the tests
> (bb-10.2-midenok-tmp).

Does it mean, you'll remove the comment (and workarounds, if any) in
your branch?

> > Also, why do you even want to re-fix items when a table alias is
> > used? Is it for MDEV-25672? But that's already fixed for half a
> > year.
> 
> Originally this fix was done before the pushed one. And do you really
> want to keep bad value in Item_field? Even if you avoid using it now
> someone surely will suffer from that after some new development or
> when new use cases happen. If there is a ready fix that eliminates
> such an accident in the future why don't you want to push it?

I generally prefer not to do work that's not needed. That's called lazy :)
If there's a value that's not used, ever, then I would suggest not to
spend time cleaning it up. Re-preparing vcols after every DML that
happened to use table aliases - that's not lazy, that's too much work.

As far as MDEV-25672 is concerned - making ALTER TABLE to check that
existing vcols refer to the correct table - that's too much work too,
we already know they do. Only new columns need to be checked.

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx


Follow ups

References