public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Tom Lane <[email protected]>
To: 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 15:40:05 +0200
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]>

On 26.09.25 18:23, Tom Lane wrote:
> No, I think the correct behavior would have to be to descend into
> SubLinks to see if they contain any aggregates belonging to the
> outer query level.
> 
> However (looks around) we do already have that code.
> See contain_aggs_of_level.  (contain_agg_clause is essentially
> a simplified version that is okay to use in the planner because
> it's already gotten rid of sublinks.)
> 
> What mainly concerns me at this point is whether we've identified
> aggregate levels at the point in parsing where you want to run this.
> I have a bit of a worry that that might interact with grouping.
> Presumably the SQL committee thought about that, so it's probably
> soluble, but ...

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.

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.

For this first patch version, I suggest you reject the use of GROUP BY 
ALL if you find a subquery in the select list, unless you have an 
unambiguous better solution.

(It was discussed to relax this restriction, so this discussion is 
useful to collect some questions related to that.)

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