From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Grant <Jan(dot)Grant(at)bristol(dot)ac(dot)uk> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Column names: where, group by, having inconsistent behaviour? |
Date: | 2004-12-02 16:42:39 |
Message-ID: | 8838.1102005759@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jan Grant <Jan(dot)Grant(at)bristol(dot)ac(dot)uk> writes:
> http://developer.postgresql.org/docs/postgres/sql-select.html
>> ... PostgreSQL also allows both clauses to specify
>> arbitrary expressions. Note that names appearing in an expression will
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> always be taken as input-column names, not as result-column names.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> select col1 as x, count(col2) as y from table1
> group by x
> having x = 1;
> should work - it's hardly ambiguous.
It violates the above-underlined restriction though.
In retrospect, the fact that we allow "GROUP BY output-column-name"
was a mistake; it extended an ugly-but-defensible frammish of ORDER BY
into a place where it should never have gone. ORDER BY is the only one
of the SELECT modifiers that is logically executed after forming the
SELECT output columns, and so it's the only one that should legitimately
have access to their values.
We're kinda stuck with this mistake now on backwards-compatibility
grounds, but I don't much want to spread the mistake any further.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | postgresbugs | 2004-12-02 16:47:28 | Re: Foreign keys referencing parent table fails on insert |
Previous Message | Tom Lane | 2004-12-02 16:35:21 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |