Arno Brinkman wrote:

>> 2. Is it well defined?
>>
>>
>
>Indeed, what should be happen for example with generators, sub-queries,
>double alias, same name known as field etc...
>
>SELECT
> FX AS FY,
> FY AS FX,
> GEN_ID(MY_GEN_ID, 1) AS ITEMID,
> (SELECT FIELD FROM TABLEX WHERE FX = FY) AS SUBS
>FROM
> TABLEY
>WHERE
> ITEMID = 1 and
> SUBS = 1 and
> FX = 1 and
> FY = 1
>
>Should a sub-select be able to use the ALIAS inside etc...
>
>

An alias reference has the same scope and visibility of the
corresponding field/expression in the select list.

>
>
>> 3. Does it violate the standard?
>>
>>
>
>I can't find anything about it that column-aliasses should be supported
>inside WHERE, GROUP BY, HAVING clauses.
>
>

Wrong question. Unless you're making commodity parts, exceeding the
standard isn't an issue.

>
>
>> 4. Is it likely to violate the standard at some future if the SQL
>> committee does something borderline plausible but dumb?
>>
>>
>
>The only problem i currently can see is what field would have the precedence
>in this query :
>
>SELECT
> F1 AS F2
>FROM
> TableX
>WHERE
> F2 = 1
>
>Where TableX has F1 and F2 as fields, should it use TableX.F1 or TableX.F2
>in the WHERE clause? May be a stupid example, but you can imagine...
>
>

An interesting philosophical question. It could be left undefined,
defined in one of at least three ways, or an explicit error. I favor
the first because the second encourages doing bonehead things and the
third strikes me as unnecessarily nasty.

>Thus your precedence is always first fields from available contextes and
>when no one found look in the select-list for aliasses?
>
>
>

Not quite. Within a context, a field has precedence over an alias. But
an alias has precedence over a earlier context.

We really should encrypt pass1.cpp so only the most experienced,

>I agree it's ugly and hard to work with. Hopefully the time will come to
>make it nice looking code with objects.
>
>
>

In the meantime, I hope folks will take a long hard look at (we'll leave
it unencrypted for that purpose) to understand why it's bad, how it got
that way, and how things like it can be avoided in the future. Note:
before Borland got their hands on it, it was a tiny, squeeky clean,
simple, heavily recursive module.


[Non-text portions of this message have been removed]