Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>Within a context, a field has precedence over an alias. But an alias
>>has precedence over a earlier context.
>>
>>
>
>Although I'm still not convienced that we need alias-based references, I'd choose this Jim's rule for possible implementation in the case it would happen. Now let's look at the suggested boundary example:
>
>SELECT F1 AS F2
>FROM TAB
>WHERE F2 = 0
>
>Usage of the aforementioned rule would mean different results to be returned depending on existence of the column F2 in TAB. Personally, I don't like it. Too many chances for a programmer's mistake. Since I never liked undefined behaviour of any kind either, this means that I'd stick with choice C in Jim's terminology, i.e. throw an ambiguity error.
>
>
>
>

Suppose you used an alias without ambiguity in a query. Then you
dropped that query into another as a subquery where the parent select
had a table in the from clause that conflicted with the alias. Is this
an error? Or is it only an error if the ambiguity occurs at the same
language level? Is the ambiguity is resolved with scoping rules are you
happy?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376