From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | David Micallef <david(dot)j(dot)micallef(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: group by true now errors with non-integer constant in GROUP BY |
Date: | 2023-08-28 21:20:27 |
Message-ID: | d5820b3a-4e0d-e8d7-130b-ce82d6509b9f@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-08-28 23:47:13 | Re: group by true now errors with non-integer constant in GROUP BY |
Previous Message | Tom Lane | 2023-08-28 19:56:00 | Re: group by true now errors with non-integer constant in GROUP BY |