Re: group by true now errors with non-integer constant in GROUP BY

On Tue, 29 Aug 2023 at 18:39, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
>
> On Tue, Aug 29, 2023 at 8:55 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >
> > On Tue, 29 Aug 2023 at 13:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > BTW, I poked around and couldn't find anything explaining this
> > > fine point in the SGML docs, although the comments in
> > > findTargetlistEntrySQL92 are clear about it. If we do anything
> > > at all here, I think that ought to include documenting the behavior
> > > more clearly (and I'm curious to see how you'd propose to explain
> > > the behavior you want to users).
> >
> > The rule and how to explain it seems fairly simple to me. Integer
> > constants are treated as column references to their corresponding
> > 1-based position in the SELECT clause. Anything else is treated as an
> > expression.
>
> Seems reasonable to me.

Here's how I think we should proceed:

1. Re-allow Boolean constants in GROUP BY in v15 and v16 by
backpatching John's fix to special case Booleans.
2. In master only, remove the special case added in #1 and allow any
non-integer constants to be treated as expressions.

I think #2 is a good move for the following reasons:

a) Seems consistent with other RDBMSs (See [1]).
b) Gets rid of the special case added in #1 to allow booleans
c) Consistent with things like "JOIN ... ON true".
d) May allow simplified coding in ORMs. Without a GROUP BY clause,
you're at the mercy of there being any aggregate functions in the
target list to define the grouping behaviour.

I've included 2 patches, 0001 for #1 (John's patch with the comment
adjusted to explain the special case) and 0002 for #2.

Does anyone think we should do this differently?

David

[1] https://postgr.es/m/CAApHDvomA1bZy=0AYUcTjDWaCeedcPeDBo6PV0VhpVeo2jG1uQ@mail.gmail.com