From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Christensen <david@pgguru.net>
cc: jian he <jian.universality@gmail.com>,
        Andrey Borodin <x4mmm@yandex-team.ru>,
        Peter Eisentraut <peter@eisentraut.org>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Jelte Fennema-Nio <postgres@jeltef.nl>
Subject: Re: [PATCH] GROUP BY ALL
In-reply-to: 
 <CAHM0NXgB7hm-JH8c1o=o-4P7LYn_EoE=XZAW0ENdtP-nso60YQ@mail.gmail.com>
References: <4D2047B0-E8D8-472B-B7E8-61206B1E6AFA@yandex-team.ru>
 <F694DABC-6A42-4614-B254-643180B9D6F6@pgguru.net>
 <CAHM0NXj1Gv_96WxZkiLKhxJVaYOGcmdZ2hApNcvWQ5HxV84Q=A@mail.gmail.com>
 <CACJufxEThXCX1QWyNE1gw--uJ4JQJ8f16MFH-kN+Ym3_02azTA@mail.gmail.com>
 <CAHM0NXg=yGzhn=H0_HiZ9u=Xq-40g1f+Bb=2e2LDxgd6a11bWw@mail.gmail.com>
 <CAHM0NXgB7hm-JH8c1o=o-4P7LYn_EoE=XZAW0ENdtP-nso60YQ@mail.gmail.com>
Comments: In-reply-to David Christensen <david@pgguru.net>
	message dated "Fri, 26 Sep 2025 12:00:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4096522.1758908779.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Sep 2025 13:46:19 -0400
Message-ID: <4096523.1758908779@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4096523.1758908779%40sss.pgh.pa.us>
Precedence: bulk

David Christensen <david@pgguru.net> writes:
> Version 3 of this patch, incorporating some of the feedback thus far:

Some random comments:

I don't love where you put the parsing code.  Instead of
exposing addTargetToGroupList, I think you should have given
transformGroupClause the responsibility of expanding GROUP BY ALL.
One reason for that is that GROUP BY processing depends on the
results of transformSortClause.  This means that in v3, the
behavior of

	 SELECT x FROM ... GROUP BY x ORDER BY x;

will be subtly different from

	 SELECT x FROM ... GROUP BY ALL ORDER BY x;

which seems like a bug, or at least not desirable.  (You might need a
DESC or USING decoration in the ORDER BY to expose this clearly.)

The parsing code itself is not great:

+			TargetEntry *n =3D (TargetEntry*)lfirst(l1);
+			if (!contain_aggs_of_level((Node *)n->expr, 0))
+				qry->groupClause =3D addTargetToGroupList(pstate, n, qry->groupClause=
, qry->targetList, 0);

You should be skipping resjunk entries, and please use "tle" or some
such name less generic than "n", and "0" is not the correct location
to pass to addTargetToGroupList.  Probably the location of the ALL
keyword would be the ideal thing, but if we don't have that, the
notation for "no location known" is -1 not 0.  We could also
consider using exprLocation(tle->expr), despite the comment on
addTargetToGroupList that that's not the right thing.  This might
actually be better than pointing at the ALL anyway, since that would
give no hint which targetentry caused the error.

The test cases seem poorly designed, because it's very hard to be
sure whether the code expanded the ALL as-expected.  I think you
could improve them by not executing the queries but just EXPLAINing
them, so that the expanded group-by list is directly visible.

			regards, tom lane