From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: Vik Fearing <vik@postgresfriends.org>,
        Dennis Brouwer <dennis.brouwer@kizitos.com>,
        John Naylor <john.naylor@enterprisedb.com>,
        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: <10a3ef130cd6d757690be076a6f47fe9351026d2.camel@cybertec.at>
References: 
 <CAJBCwCS7OuEUmGkrnu5Q8SmBP10njnEiX7vJiaxJURZXcCORyw@mail.gmail.com>
 <CAFBsxsE_zy1Y=u2ZM6xZHFY2Cwfr_Uii=-irsHtCxrh6GnfBNA@mail.gmail.com>
 <837886.1693252560@sss.pgh.pa.us>
 <CAF31W9qz7qXxp=LADZv3+Y1CtJio5cvbU2FcbRyB9nW+R45xQg@mail.gmail.com>
 <3af446dd6fbfdb6e08de95fc24e06081f78a6f15.camel@cybertec.at>
 <18ba0d29-0637-48c5-a11d-19f8672a8b0f@postgresfriends.org>
 <10a3ef130cd6d757690be076a6f47fe9351026d2.camel@cybertec.at>
Comments: In-reply-to Laurenz Albe <laurenz.albe@cybertec.at>
	message dated "Fri, 20 Oct 2023 08:32:57 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3970726.1697828605.1@sss.pgh.pa.us>
Date: Fri, 20 Oct 2023 15:03:25 -0400
Message-ID: <3970727.1697828605@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3970727.1697828605%40sss.pgh.pa.us>
Precedence: bulk

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> I agree that it is desirable to fix this regression.

It's not a regression.  If anything, it's a bug fix, because the
code is now doing what it intended to do all along: reject all
non-integral constants.  The previous behavior was exposing an
implementation detail, namely that "true" wasn't a simple literal
constant according to the older grammar.  But all of these were
and still are rejected:

	GROUP BY 'true';
	GROUP BY 1.0;
	GROUP BY null;

I'm not really satisfied with concluding that we need to be
bug-compatible (literally) with an old implementation wart forever.

> Still, we shouldn't exonerate Hibernate from fixing the junk SQL
> it produces.

I'm curious as to how this incompatibility escaped notice for a full
year.  Does Hibernate emit this SQL only in narrow corner cases?

			regards, tom lane