From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: asterisk (non)expansion in GROUP BY clause |
Date: | 2011-05-20 11:50:37 |
Message-ID: | 8132.1305892237@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Apparently, you can write this (an attempt at a convenient workaround
> for lack of functional dependency tracking pre-9.1):
> SELECT pg_class.* FROM pg_class GROUP BY pg_class.*;
> It won't work:
> ERROR: 42803: column "pg_class.relname" must appear in the GROUP BY clause or be used in an aggregate function
I haven't traced through the code, but I think what is happening is that
the GROUP BY is interpreted like GROUP BY ROW(pg_class.x, pg_class.y, ...)
which doesn't guarantee uniqueness of the individual columns.
The star notation in the target list is interpreted differently: it
results in an explicit expansion into separate Var references. And then
those fail the grouping check since they're not forced unique by the
GROUP BY clause.
> Is there any rhyme or reason for this? I couldn't find anything about
> this in the documentation or in the SQL standard. I guess the whole
> thing is inconsistent all over the place; I'd just like to verify that
> the current behavior is somewhat intentional.
The behavior in the target list is mandated by SQL spec, for sure.
But I doubt that the spec defines the above GROUP BY syntax at all.
I wouldn't claim that the current behavior in GROUP BY is "intentional"
--- it's not a case that I ever thought about, anyway. Not sure how
practical it would be to change that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-20 15:27:08 | Re: ts_rank |
Previous Message | Emanuel Calvo | 2011-05-20 09:02:57 | Error compiling sepgsql in PG9.1 |