Horton

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

Andrew Gierth <andrew@tao11.riddles.org.uk>

View thread View on postgr.es
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2017-10-16T03:50:15Z
Lists: 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 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)

Commits

  1. Fix incorrect handling of subquery pullup in the presence of grouping sets.

  2. Make setrefs.c match by ressortgroupref even for plain Vars.

  3. Make the upper part of the planner work by generating and comparing Paths.