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 →
  1. Add GROUP BY ALL.

  2. Refactor to avoid code duplication in transformPLAssignStmt.

  3. Fix missed copying of groupDistinct in transformPLAssignStmt.

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