Re: Column names: where, group by, having inconsistent behaviour?

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

In response to

Browse pgsql-bugs by date

  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