List:Commits« Previous MessageNext Message »
From:Konstantin Osipov Date:November 23 2007 10:29am
Subject:Re: bk commit into 5.2 tree (davi:1.2610) BUG#27525
View as plain text  
* Davi Arnaut <davi@stripped> [07/11/23 04:45]:
> >> ChangeSet@stripped, 2007-10-08 08:38:07-03:00, davi@stripped +6 -0
> >>   Bug#27525 table not found when using multi-table-deletes with aliases over
> several databas
> >>   
> > 
> > 1) There are two syntaxes of MULTI-DELETE:
> >    DELETE <list> FROM <list> WHERE ...
> >    and
> >    DELETE FROM <list> USING <list> WHERE ...
> > 
> >    Both should be fixed and covered with tests.
> 
> Thinking more about it, I believe some cases that the cparser is
> accepting are bugs and we should disallow aliases in the first <list>
> and always threat then as table names. It's not worth the trouble, alias
> are only really worth on the second list where they can be used in the
> where_condition. For example, the parser is accepting weird/ambiguous
> statements like:
> 
> DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
> 
> Resolving this kind of ambiguity would require multiple passes over the
> list and serves no purpose what-so-ever. Can we scrap alias support from
> the table name list?

No, I'm afraid we can't.

Remember, this is essentially a feature request, since the
limitation is documented.
It's a non-standard mysql extension added back in 4.0.

If we break current applications, we will be lynched.

> > 3) Please also add tests that demonstrate the conflict resolution
> >    between an assigned alias and a database name:
> > 
> >    DELETE t1, db1.t1 FROM t2 as t1, db1.t1 -- ?
> 
> No, this one is another example we shouldn't allow the alias. This query
> should mean:
> 
> DELETE selected_db.t1, db1.t1 FROM selected_db.t2 AS t1, db1.t1 --
> 
> and spill out a error (non-unique or not in the from list, depending on
> the selected_db).

I suggest we just make sure that it works as before -- if anyone
does not like the ambiguity, they will report a separate bug and
we fix it.

-- 
-- Konstantin Osipov              Software Developer, Moscow, Russia
-- MySQL AB, www.mysql.com   The best DATABASE COMPANY in the GALAXY
Thread
bk commit into 5.2 tree (davi:1.2610) BUG#27525Davi Arnaut8 Oct
  • Re: bk commit into 5.2 tree (davi:1.2610) BUG#27525Konstantin Osipov22 Nov
    • Re: bk commit into 5.2 tree (davi:1.2610) BUG#27525Davi Arnaut23 Nov
      • Re: bk commit into 5.2 tree (davi:1.2610) BUG#27525Konstantin Osipov23 Nov