Re: [PATCH] GROUP BY ALL
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: David Christensen <david@pgguru.net>,
Andrey Borodin <x4mmm@yandex-team.ru>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Jelte Fennema-Nio <postgres@jeltef.nl>
Date: 2025-09-27T16:03:10Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add GROUP BY ALL.
- ef38a4d9756d 19 (unreleased) landed
-
Refactor to avoid code duplication in transformPLAssignStmt.
- b0fb2c6aa5a4 19 (unreleased) landed
-
Fix missed copying of groupDistinct in transformPLAssignStmt.
- b7f6798c056a 16.11 landed
- 9ca79896aba3 15.15 landed
- 78a284b0b8d4 18.1 landed
- 7504d2be9eb4 19 (unreleased) landed
- 3fc9aa5b0233 17.7 landed
- 0be39b4b1a01 14.20 landed
Peter Eisentraut <peter@eisentraut.org> writes: > The language used in the standard at the moment is the select list > elements that "do not directly contain an <aggregate function>", where > "directly contain" is a term of art that means "contains without an > intervening instance of <subquery>, <within group specification>, or > <set function specification> that is not an <ordered set function>". So > it means not to look into subqueries. TBH, that is obvious nonsense. A subquery could contain an aggregate function that we've already identified as being of the current query level. Putting such a construct into the GROUP BY list would create an invalid query (cf. checkTargetlistEntrySQL92). Similarly, putting a window function into the GROUP BY list would create an invalid query. > Note that in standard SQL, the GROUP BY clause can only contain plain > column references, not expressions, so this question is kind of moot in > that context, because the query would be invalid no matter whether you > transform the GROUP BY ALL to group by the subquery or not. So according to the standard, this: select a+b, count(*) from ... group by all; would be invalid because a+b couldn't be written directly in GROUP BY? I can't see us rejecting that though, since we do allow a+b in GROUP BY. Seems like we're getting very little help from the standard as to what this construct actually means. I suggest that we ignore the current draft as not having been thought through quite enough yet, and make ALL skip any tlist entries that contain_aggs_of_level zero or contain_windowfuncs. If that means we're extending the standard, so be it --- we've already extended GROUP BY quite a lot, it seems. regards, tom lane