From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@enterprisedb.com>
cc: David Micallef <david.j.micallef@gmail.com>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: group by true now errors with non-integer constant in GROUP BY
In-reply-to: 
 <CAFBsxsE_zy1Y=u2ZM6xZHFY2Cwfr_Uii=-irsHtCxrh6GnfBNA@mail.gmail.com>
References: 
 <CAJBCwCS7OuEUmGkrnu5Q8SmBP10njnEiX7vJiaxJURZXcCORyw@mail.gmail.com>
 <CAFBsxsE_zy1Y=u2ZM6xZHFY2Cwfr_Uii=-irsHtCxrh6GnfBNA@mail.gmail.com>
Comments: In-reply-to John Naylor <john.naylor@enterprisedb.com>
	message dated "Mon, 28 Aug 2023 16:24:32 +0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <837885.1693252560.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Aug 2023 15:56:00 -0400
Message-ID: <837886.1693252560@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/837886.1693252560%40sss.pgh.pa.us>
Precedence: bulk

John Naylor <john.naylor@enterprisedb.com> writes:
> On Mon, Aug 28, 2023 at 1:28=E2=80=AFPM David Micallef <david.j.micallef=
@gmail.com>
> wrote:
>> ERROR:  non-integer constant in GROUP BY

> I can confirm the reproducer script fails with commit 941460fcf731a ("Ad=
d
> Boolean node"). (So actually all 15.x were affected.)

Yeah, same result from bisecting here.  I had had the idea that this
was an intentional semantics change to reduce the probability of error,
but that commit didn't mention any such thing, so that's a tough claim
to make as far as the historical intent goes.

Having said that ... it seems to me that it was pure coincidence that
"group by true" worked before, and I'm not sure we should install a
grotty hack to make it work again.  In particular, why should we allow
Boolean Consts but not other non-integer Consts?  (And if we do, don't
we need to change that error message?)

The bigger picture here is: what is the use-case for grouping by a
constant at all?  Assuming that it is an error seems like a good
foolproofing restriction.  The reason we felt we could keep the
"group by N" SQL92-ism after SQL99 redefined GROUP BY arguments is
exactly that there's no obvious use-case for grouping by a constant.
As soon as you allow it, "group by N" becomes hopelessly ambiguous.

So my druthers would be to reject this as a non-bug.  But if we accept
it as something to fix, we need to revisit exactly which conditions
are errors here.  Perhaps rather than "reject all non-integer cases",
we should only reject the Float case, and let others fall through to
the SQL99 code.  (I would not be happy allowing Float, because that'd
mean that "group by 4" and "group by 4.0" mean fundamentally different
things.)

			regards, tom lane