I take it all back. I see now why this behaviour is desirable, or at least standard.
E.g., see: https://aurora.vcu.edu/db2help/db2s0/c2corr.htm On Apr 4, 2005 2:40 PM, Tom Cunningham <[EMAIL PROTECTED]> wrote: > Hi, the following seems wrong to me. Not sure whether this is a bug. > > In short: a column-name in a subquery can refer to a table *outside* > of the subquery (fair enough), but if the column-name is ambiguous > between *inside* and *outside*, the parser assumes that it refers to > the *inside* context. > > I would have thought it better to reject the query where it is ambiguous. > > Tom. > > -------- > > drop table t1; > create table t1 (c1 int); > > drop table t2; > create table t2 (c2 int); > > delete from t1 where c1 not in (select c1 from t2); > > works, & slightly confusing, but reasonable > ---------- > > drop table t1; > create table t1 (c int); > > drop table t2; > create table t2 (c int); > > delete from t1 where c not in (select c from t2); > > this query works, but resolves the ambiguity in the *opposite* > way to above. The subquery column now refers to the inside subquery. > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
