From: | Jan Grant <Jan(dot)Grant(at)bristol(dot)ac(dot)uk> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Column names: where, group by, having inconsistent behaviour? |
Date: | 2004-12-02 15:04:26 |
Message-ID: | Pine.GSO.4.61.0412021451140.26436@mail.ilrt.bris.ac.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Apologies for raising this - I've found a message in the
archives from about a month ago; but...
I can't find the relevant sections in the SQL spec; nevertheless, the
docs for the SELECT command lead me to believe that this should work,
since:
http://developer.postgresql.org/docs/postgres/sql-select.html
[[
In the SQL-92 standard, an ORDER BY clause may only use result column
names or numbers, while a GROUP BY clause may only use expressions based
on input column names. PostgreSQL extends each of these clauses to allow
the other choice as well (but it uses the standard's interpretation if
there is ambiguity). 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.
]]
Sure enough:
select col1 as x, col2 as y from table1 order by x;
...works, as does:
select col1 as x, count(col2) as y from table1
group by x
having count(col2) = 1;
"Having" operates after "group by"; and I'd argue that
[[
Each column referenced in condition must unambiguously reference a
grouping column, unless the reference appears within an aggregate
function.
]]
so since we can "group by x", one would imagine that
select col1 as x, count(col2) as y from table1
group by x
having x = 1;
should work - it's hardly ambiguous.
I appreciate the distinction between input and output columns;
nevertheless, the loosening of the behaviour of "group by" doesn't seem
to sit with the restriction on "having". I also appreciate the need to
support "standard" sql - but in the absence of ambiguities, shouldn't
this expression "do what I mean"?
Cheers,
jan
--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287864 or +44 (0)117 9287088 http://ioctl.org/jan/
You see what happens when you have fun with a stranger in the Alps?
From | Date | Subject | |
---|---|---|---|
Next 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 |
Previous Message | Alvaro Herrera | 2004-12-02 14:15:38 | Re: oid2name core dump |