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: pgsql-hackers <pgsql-hackers@postgresql.org>,
"David G. Johnston" <david.g.johnston@gmail.com>,
David Christensen <david@pgguru.net>,
Jelte Fennema-Nio <postgres@jeltef.nl>
Date: 2025-09-26T20:18:32Z
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 →
-
Add GROUP BY ALL.
- ef38a4d9756d 19 (unreleased) landed
-
Refactor to avoid code duplication in transformPLAssignStmt.
- b0fb2c6aa5a4 19 (unreleased) landed
-
Fix missed copying of groupDistinct in transformPLAssignStmt.
- b7f6798c056a 16.11 landed
- 9ca79896aba3 15.15 landed
- 78a284b0b8d4 18.1 landed
- 7504d2be9eb4 19 (unreleased) landed
- 3fc9aa5b0233 17.7 landed
- 0be39b4b1a01 14.20 landed
Peter Eisentraut <peter@eisentraut.org> writes:
> On 26.09.25 16:11, Tom Lane wrote:
>> I thought I understood this definition, up till your last
>> comment. What's invalid about that expanded query?
> This was a sloppy example. Here is a better one:
> create table t1 (a int, b int, c int);
> select a, sum(b)+c from t1 group by all;
> This is equivalent to
> select a, sum(b)+c from t1 group by a;
> which would be rejected as
> ERROR: column "t1.c" must appear in the GROUP BY clause or be used
> in an aggregate function
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? The second case is outside the
SQL spec so I'm not expecting guidance on that, but surely the
committee thought about the first case.
Also, what about window functions in the tlist? If you do
regression=# explain select sum(q1) over(partition by q2) from int8_tbl group by 1;
you get
ERROR: window functions are not allowed in GROUP BY
LINE 1: explain select sum(q1) over(partition by q2) from int8_tbl g...
^
but that's not what is happening with
regression=# explain select sum(q1) over(partition by q2) from int8_tbl group by all;
ERROR: column "int8_tbl.q2" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: explain select sum(q1) over(partition by q2) from int8_tbl g...
^
(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.
regards, tom lane