From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Robert J(dot)C(dot) Ivens" <robert(at)roclasi(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Using column aliasses in the same query |
Date: | 2011-04-17 16:00:39 |
Message-ID: | 25012.1303056039@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Robert J.C. Ivens" <robert(at)roclasi(dot)com> writes:
> I am not sure if there ever was a feature request for using defined
> column aliases in the rest of a query.
Yes, we've heard that before. Many times. It's not going to happen,
and here's why: it's flat out contrary to the SQL specification, as well
as to the basic intuitive semantics of SQL. The SELECT list is supposed
to be evaluated as the last step of a query (well, last except for ORDER
BY, which is why there's an exception for that). It's nonsensical for
WHERE etc to depend on the results of the SELECT list.
As an example of why this is important, consider
SELECT x/y AS z FROM tab WHERE y <> 0
If the WHERE clause doesn't act before the SELECT list is computed,
the query is going to fail with divisions-by-zero, exactly what the
WHERE clause is trying to prevent. So it'd be nonsensical to refer
to z in the WHERE clause.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Farber | 2011-04-17 18:05:55 | Installing PGDG on a fresh CentOS 5.6 |
Previous Message | Jack Douglas | 2011-04-17 15:55:51 | "interval hour to minute" or "interval day to minute" |