public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: David Christensen <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Subject: Re: [PATCH] GROUP BY ALL
Date: Sat, 27 Sep 2025 15:30:29 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAHM0NXjz0kDwtzoe-fnHAqPB1qA8_VJN0XAmCgUZ+iPnvP5LbA@mail.gmail.com>
	<CAKFQuwY0vhNG8T+pC3BQJurFi3NN_L1KbEPGagRN3V5nKZcpDQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAGECzQSGKWy1tcB8BB=p2suOvW0KLtLR+pm=XTagfp9WSA4HXQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 26.09.25 22:18, Tom Lane wrote:
> Got it, mostly.  There is an edge case, though: what if there are no
> candidate grouping items?  I see these test cases in David's patch:
> 
> +-- oops all aggregates
> +EXPLAIN (COSTS OFF) SELECT COUNT(a), SUM(b) FROM t1 GROUP BY ALL;
> +      QUERY PLAN
> +----------------------
> + Aggregate
> +   ->  Seq Scan on t1
> +(2 rows)
> +
> +-- empty column list
> +EXPLAIN (COSTS OFF) SELECT FROM t1 GROUP BY ALL;
> +   QUERY PLAN
> +----------------
> + Seq Scan on t1
> +(1 row)
> 
> That is, in such cases the patch behaves as if there were no GROUP BY
> clause at all, which seems kinda dubious.  Should this be an error,
> and if not what's it supposed to do?

These should resolve to GROUP BY ().

> Also, what about window functions in the tlist?

> (I didn't stop to figure out why this isn't giving the same error, but
> maybe it's an order-of-checks thing.)  In any case: should this give
> "window functions are not allowed in GROUP BY", or should the
> window-function-containing tlist item be silently skipped by GROUP BY
> ALL?  Trying to make it work is surely not the right answer.

Hmm, I don't know.  The syntactic transformation talks about select list 
elements that "do not directly contain an <aggregate function>", but 
that can also appear as part of <window function>, so the syntactic 
transformation might appear to apply only to some types of window 
functions, which doesn't make sense to me.

I don't know what a sensible behavior should be here.  Maybe in this 
first patch version just reject use of GROUP BY ALL if you find any 
window functions in the select list.

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]
  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