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>
Subject: Re: [PATCH] GROUP BY ALL
In-reply-to: <3d01eb20-d587-4dec-9261-0c92240ce546@eisentraut.org>
References: 
 <CAHM0NXjz0kDwtzoe-fnHAqPB1qA8_VJN0XAmCgUZ+iPnvP5LbA@mail.gmail.com>
 <CAKFQuwY0vhNG8T+pC3BQJurFi3NN_L1KbEPGagRN3V5nKZcpDQ@mail.gmail.com>
 <931747.1721687375@sss.pgh.pa.us>
 <b46070c0-0e98-49a0-823f-fa7e13bf626b@eisentraut.org>
 <CAGECzQSGKWy1tcB8BB=p2suOvW0KLtLR+pm=XTagfp9WSA4HXQ@mail.gmail.com>
 <634aca95-6db5-4beb-b18d-67e65582817f@eisentraut.org>
 <4054709.1758895915@sss.pgh.pa.us>
 <3d01eb20-d587-4dec-9261-0c92240ce546@eisentraut.org>
Comments: In-reply-to Peter Eisentraut <peter@eisentraut.org>
	message dated "Fri, 26 Sep 2025 17:54:18 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4174778.1758917912.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Sep 2025 16:18:32 -0400
Message-ID: <4174779.1758917912@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4174779.1758917912%40sss.pgh.pa.us>
Precedence: bulk

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=3D# 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=3D# 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