Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2017-10-18T15:42:38Z
Lists: pgsql-bugs

Attachments

I wrote:
> I think that Heikki's expectation is the correct one, and the reason the
> output looks the way it does is that setrefs.c is dropping the ball
> somehow and confusing the two "g" references.  ...
> We should have used ressortgroupref matching to prevent this, but without
> having checked the code right now, I think that we might only apply that
> logic to non-Var tlist entries.  If the Agg output tlist had mentioned
> column 2 not column 1 of the child node, I bet we'd get the right answer.

Indeed, the attached patch passes all regression tests and produces the
same answers for both of Heikki's examples:

regression=# SELECT g as newalias1, g as newalias3
FROM generate_series(1,3) g
GROUP BY newalias1, ROLLUP(newalias3);
 newalias1 | newalias3 
-----------+-----------
         1 |         1
         3 |         3
         2 |         2
         2 |          
         3 |          
         1 |          
(6 rows)


			regards, tom lane

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.