On Tue, 26 Nov 2002 dev@archonet.com wrote:
> > On Tue, 26 Nov 2002, Richard Huxton wrote:
> >
> >> On Tuesday 26 Nov 2002 9:43 am, patrick wrote:
> >> > Greetings,
> >> >
> >> > I'm not sure what the correct behavior is here but the observed
> >> > behavior seems "wrong" (or at least undesirable).
>
> >> Don't look right to me, and I still see it here in 7.2 and the 7.3 beta
> >> I've
> >> got (note - not most recent). I don't think it's in the subselect itself
> >> -
> >> what's happening is when you do
> >
> > I think it's standard behavior. The column reference is an outer
> > reference I believe, IIRC all the names from the outer query are in scope
> > in the subselect (although if there's an equivalent name in the subselect
> > from tables you'd have to qualify it).
>
> Ah - of course. Otherwise you couldn't do a subselect where foo=outer_foo.
> It tries to bind within the subselect, fails, then binds to the outer
> clause.
>
> Obvious now Stephan's pointed it out. Also reminds me why I like table
> aliases for any complicated queries.
Yeah, they could have (or at least if they did I couldn't find it this
morning) required at least table qualifying outer references. That would
have let the same functionality at the cost of only a few extra
characters while being more obvious. It'd mean that you'd have to table
alias things in subselects where you wanted to get to the same tablename
in a higher scope, but it wouldn't have been that bad.