>>>SELECT ID, RELATIEID AS ALIAS
>>> FROM Orders
>>> WHERE ALIAS = 3668

...

> A glance at the standard suggests that X AS Y in the select
> list is called <derived column> AS <column name>. The
> restrictions on the use of a <derived column> appear to be:

It seems to me that these rules are talking about the derived
column rather than the alias. That is; what can and cannot
happen if a column is "derived" (an expression). They dont
seem to be directly applicable to just using aliases.

I would hate to see the use of an alias to a "normal" column
interpretted as a derived column (expression). This would
effect such things as optimisation and destroy the potential
usefulness of aliases. eg:

SELECT INDEXED_COL AS ICOL
FROM ATABLE
WHERE ICOL = 'some value';

Should functionally equivalent to

SELECT INDEXED_COL AS ICOL
FROM ATABLE
WHERE INDEXED_COL = 'some value';


However your quoting of the rules does beg the question about
what to do with actual derived columns (expressions)...

SELECT (ACOL + BCOL) AS XCOL
FROM ATABLE
WHERE XCOL = 25;

Is this the same as:

SELECT (ACOL + BCOL) AS XCOL
FROM ATABLE
WHERE (ACOL + BCOL) = 25;

(ie. the derivation of the value is actually performed twice,
which could be important in more complicated derivations)

or will it be possible to make the alias actually reference
the value from the extracted row data. eg:

SELECT (ACOL + BCOL) AS XCOL
FROM ATABLE
WHERE <value of field 1> = 25;

that is; like using an ordinal in an ORDER BY clause.

To me this second alternative would be preferable, I have no
idea if it is practical - or whether it violates the standard
(I need to get my language lawyer in before I can understand
the meaning of what you posted from the standard :-).

--
Geoff Worboys
Telesis Computing