Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
Date
Msg-id 87efq3lq93.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
List pgsql-bugs
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I propose the attached patch to fix that. It forces the use of>> PlaceHolderVars in subquery pullup, if the parent
queryhas 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 beTom> subject to the problem. I'm a bit surprised
thatthe "x" in theTom> targetlist didn't become a constant as well. This may be pointingTom> to some klugery in the
GROUPINGSETS patch that we could clean upTom> 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)


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] Combination of ordered-set aggregate function terminates JDBC connection on PostgreSQL 9.6.5
Next
From: Eduardo Pérez Ureta
Date:
Subject: Re: [BUGS] BUG #14853: Parameter type is required even when the querydoes not need to know the type