Re: Improper const-evaluation of HAVING with grouping sets and subquery pullup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Improper const-evaluation of HAVING with grouping sets and subquery pullup
Date: 2017-10-25 19:29:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

I wrote:
>> We should have used ressortgroupref matching to prevent this, but without
>> having checked the code right now, I think that we might only apply that
>> logic to non-Var tlist entries. If the Agg output tlist had mentioned
>> column 2 not column 1 of the child node, I bet we'd get the right answer.

> Indeed, the attached patch passes all regression tests and produces the
> same answers for both of Heikki's examples:

I did some back-porting work on this. The patch applies back to 9.5
where grouping sets were introduced, but it only fixes the problem
in 9.6 and later --- in 9.5, you still get the wrong output :-(.

Bisecting says the behavior changed at commit 3fc6e2d7f "Make the upper
part of the planner work by generating and comparing Paths". Ugh.
We are certainly not back-patching that into 9.5, and I'm disinclined
even to try to identify exactly why that commit changed the behavior.

Given that this is such a weird corner case, and we've not heard
complaints from actual users about it, I'm inclined just to apply
the patch in 9.6 and up and call it good.

regards, tom lane

Attachment Content-Type Size
check-sortgroupref-for-Vars-too-2.patch text/x-diff 3.0 KB

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message dcwatson 2017-10-25 20:04:57 BUG #14872: libpq requires a home directory
Previous Message Michael Paquier 2017-10-25 15:32:52 Re: BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much