On Fri, May 9, 2025 at 11:47 AM Richard Guo <guofengli...@gmail.com> wrote: > On Fri, May 9, 2025 at 12:18 AM Bruce Momjian <br...@momjian.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 <br...@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? > > 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
