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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Column names: where, group by, having inconsistent behaviour?
Дата
Msg-id 8838.1102005759@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Column names: where, group by, having inconsistent behaviour?  (Jan Grant <Jan.Grant@bristol.ac.uk>)
Список pgsql-bugs
Jan Grant <Jan.Grant@bristol.ac.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Следующее
От: postgresbugs
Дата:
Сообщение: Re: Foreign keys referencing parent table fails on insert