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@momjian.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?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
