Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1qajf4-00AFQe-U2
	for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Aug 2023 21:20:38 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1qajf2-00G35i-Qq
	for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Aug 2023 21:20:36 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <andrew@dunslane.net>)
	id 1qajf2-00G35D-HK
	for pgsql-bugs@lists.postgresql.org; Mon, 28 Aug 2023 21:20:36 +0000
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by magus.postgresql.org with esmtps  (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <andrew@dunslane.net>)
	id 1qajey-001blQ-Kx
	for pgsql-bugs@lists.postgresql.org; Mon, 28 Aug 2023 21:20:35 +0000
Received: by mail.gandi.net (Postfix) with ESMTPSA id 07B5DE0003;
	Mon, 28 Aug 2023 21:20:28 +0000 (UTC)
Content-Type: multipart/alternative;
 boundary="------------UnwclEC0kC7ExR0SnZntyQrQ"
Message-ID: <d5820b3a-4e0d-e8d7-130b-ce82d6509b9f@dunslane.net>
Date: Mon, 28 Aug 2023 17:20:27 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: group by true now errors with non-integer constant in GROUP BY
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, 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
References: 
 <CAJBCwCS7OuEUmGkrnu5Q8SmBP10njnEiX7vJiaxJURZXcCORyw@mail.gmail.com>
 <CAFBsxsE_zy1Y=u2ZM6xZHFY2Cwfr_Uii=-irsHtCxrh6GnfBNA@mail.gmail.com>
 <837886.1693252560@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <837886.1693252560@sss.pgh.pa.us>
X-GND-Sasl: adsend@dunslane.net
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/d5820b3a-4e0d-e8d7-130b-ce82d6509b9f%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------UnwclEC0kC7ExR0SnZntyQrQ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 2023-08-28 Mo 15:56, Tom Lane wrote:
>
> 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.)
>
> 			


I vote for treating it as a non-bug.


cheers


andrew


--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------UnwclEC0kC7ExR0SnZntyQrQ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2023-08-28 Mo 15:56, Tom Lane wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:837886.1693252560@sss.pgh.pa.us"><br>
      <pre class="moz-quote-pre" wrap="">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.)

			</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I vote for treating it as a non-bug.</p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------UnwclEC0kC7ExR0SnZntyQrQ--