Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
От | Andrew Gierth |
---|---|
Тема | Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup |
Дата | |
Msg-id | 87efq3lq93.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
|
Список | 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 по дате отправления: