From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-16 03:50:15 |
Message-ID: | 87efq3lq93.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I propose the attached patch to fix that. It forces the use of
>> PlaceHolderVars in subquery pullup, if the parent query has grouping
>> sets and HAVING. I'm not 100% sure that's the right approach or a
>> misuse of the placeholder system, so comments welcome.
I've been testing Heikki's patch with the havingQual condition removed,
and I haven't found any issues yet.
Tom> One thing I'm wondering is why only the HAVING clause would be
Tom> subject to the problem. I'm a bit surprised that the "x" in the
Tom> targetlist didn't become a constant as well. This may be pointing
Tom> to some klugery in the GROUPING SETS patch that we could clean up
Tom> if we use placeholders for this.
As far as I can tell, the "x" _does_ become a constant, but then in
setrefs, because it's still labelled with a sortgroupref, it gets
replaced by a Var again. I don't recall touching any of that in the GS
work, because it was already like that for plain GROUP BY.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Eduardo Pérez Ureta | 2017-10-16 05:40:36 | Re: BUG #14853: Parameter type is required even when the query does not need to know the type |
Previous Message | Tom Lane | 2017-10-16 03:11:11 | Re: Combination of ordered-set aggregate function terminates JDBC connection on PostgreSQL 9.6.5 |