* 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