public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: David Christensen <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Subject: Re: [PATCH] GROUP BY ALL
Date: Sat, 27 Sep 2025 12:03:10 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CAHM0NXj1Gv_96WxZkiLKhxJVaYOGcmdZ2hApNcvWQ5HxV84Q=A@mail.gmail.com>
	<[email protected]>
	<CAHM0NXgPhe_OF81MyA9ocWZ=b+oEAHtQHoDXw4DverPdbkXzpg@mail.gmail.com>
	<[email protected]>
	<[email protected]>

Peter Eisentraut <[email protected]> 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

view thread (49+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] GROUP BY ALL
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox