Re: [SQL] Re: [HACKERS] Counting bool flags in a complex query

Michael Richards <miker(at)scifair(dot)acadiau(dot)ca> writes:
>> For example,
>>
>> create table z1 (f1 int4, f2 int4);
>> CREATE
>> select f1 as f2, f2 from z1 order by f2;
>> f2|f2
>> --+--
>> (0 rows)
>>
>> Which column do you think it's ordering by? Which column *should* it
>> order by? I think this ought to draw an "ambiguous column label" error

> Good point. Is there anything in the SQL standard that defined how this
> "is supposed" to work?

After looking at the SQL spec I think the above definitely ought to draw
an error. We have the following verbiage concerning the column names
for the result of a SELECT:

a) If the i-th <derived column> in the <select list> specifies
an <as clause> that contains a <column name> C, then the
<column name> of the i-th column of the result is C.

b) If the i-th <derived column> in the <select list> does not
specify an <as clause> and the <value expression> of that
<derived column> is a single <column reference>, then the
<column name> of the i-th column of the result is C.

c) Otherwise, the <column name> of the i-th column of the <query
specification> is implementation-dependent and different
from the <column name> of any column, other than itself, of
a table referenced by any <table reference> contained in the
SQL-statement.

which Postgres does indeed follow, and we see from (a) and (b) that "f2"
is the required column name for both columns of the SELECT result.
Now ORDER BY says

a) If a <sort specification> contains a <column name>, then T
shall contain exactly one column with that <column name> and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the <sort specification> identifies that column.

which sure looks to me like it mandates an error for the example
statement.

However, since SQL doesn't consider the possibility of expressions as
ORDER BY entries, we are more or less on our own for those. An
expression appearing in the target list of a SELECT is not allowed to
refer to columns by their "AS" names (and this does seem to be mandated
by SQL92). So I think it makes sense to carry over the same restriction
to ORDER BY.

regards, tom lane