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-15T12:42:52Z
Lists: pgsql-bugs 
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 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.

This shows that the problem can extend to the targetlist too:

select four, x || 'x'
  from (select four, ten, 'foo'::text as x from tenk1 ) as t
 group by grouping sets(four, x);

 four | ?column? 
------+----------
    3 | foox
    0 | foox
    1 | foox
    2 | foox
      | foox
(5 rows)

What seems to happen in the original case is that the 'foo' constant
ends up in the projection of the input to the aggregate node, with a Var
in the output.

-- 
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.