Re: PG 18 release notes draft committed

On Fri, May 9, 2025 at 11:47 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> On Fri, May 9, 2025 at 12:18 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Thu, May 8, 2025 at 07:46:11PM +0900, Richard Guo wrote:
> > > On Thu, May 8, 2025 at 5:41 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > > On Wed, May 7, 2025 at 03:03:32PM +0900, Richard Guo wrote:
> > > > > I'm wondering if we should consider mentioning that several
> > > > > long-standing issues related to grouping sets have been fixed starting
> > > > > from PostgreSQL v18. I understand that we typically don't include bug
> > > > > fixes in the release notes, but these particular issues have been
> > > > > present since grouping sets were first introduced, and currently they
> > > > > still exist in the back branches (yeah, for some reason we do not have
> > > > > back-branch fixes; we only fix them in v18 and going forward).
> > > > >
> > > > > There have been complaints from users about grouping sets giving
> > > > > incorrect results in certain cases, which has made them hesitant to
> > > > > use PostgreSQL for analytical workloads. Since these issues are fixed
> > > > > in v18, it might be worthwhile to point this out — if only to reassure
> > > > > users that these issues are no longer a concern going forward.
> > > > >
> > > > > (FWIW, the related commits are 247dea89f, f5050f795, and cc5d98525).
> > > >
> > > > Agreed, any fix that commonly used to return wrong results should be
> > > > mentioned. Applied patch attached.
> > >
> > > I'm not sure whether it's appropriate to put the incorrect-result
> > > fixes under the item "Allow some HAVING clauses on GROUPING SETS to
> > > be pushed to WHERE clauses", since that item is an optimization and
> > > does not fix these incorrect-result issues.
> > >
> > > But I'm also unsure where else they should go. Would it make sense to
> > > list them as a new item instead?
> >
> > I put it there because that is the only mention of GROUPING SETS. If we
> > create a separate item, would the text just be "This release fixes
> > some GROUPING SETS queries that used to return incorrect results." Is
> > there any pattern to the fix? Seems NULLs or subqueries were involved.
> > Is this an incompatibility? Could people be relying on the old
> > behavior?
>
> I think there are two patterns here:
>
> * 247dea89f and cc5d98525 fix cases where grouping expressions fail to
> match lower-level target items due to expression preprocessing or
> subquery pull-up. Subqueries are one example of such expressions.
>
> * f5050f795 fixes cases where some seemingly redundant grouping or
> ordering expressions were incorrectly ignored, without recognizing
> that they could be nulled by grouping sets.
>
> I don't think this constitutes an incompatibility, and it's unlikely
> that anyone is relying on the old behavior, as it was clearly
> incorrect.
>
> (I realize these descriptions are too technical, but I'm not sure how
> to express them in a more user-facing way.)

How about putting them this way:

* 247dea89f and cc5d98525 fix queries in which GROUP BY columns
contain expressions that are complex or originate from subqueries.

* f5050f795 fixes queries in which ORDER BY columns contain
expressions that are used in grouping sets.

Thanks
Richard