Re: [PATCH] GROUP BY ALL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: David Christensen <david(at)pgguru(dot)net>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Subject: Re: [PATCH] GROUP BY ALL
Date: 2025-09-27 16:03:10
Message-ID: 167505.1758988990@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-27 16:43:49 Re: test_json_parser/002_inline is kind of slow
Previous Message Dilip Kumar 2025-09-27 15:54:15 Re: Proposal: Conflict log history table for Logical Replication