]> granicus.if.org Git - postgresql/commit
Fix incorrect handling of subquery pullup in the presence of grouping sets.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 12 Jan 2018 17:24:50 +0000 (12:24 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 12 Jan 2018 17:24:50 +0000 (12:24 -0500)
commit6520d4a9692882a7d5233dac40c4b7ff07f55049
treefbdffb174ac4696a4ef9750721d3713172462348
parentbda5281fdc5e41b6f54ff8f47df2ca37df00a19e
Fix incorrect handling of subquery pullup in the presence of grouping sets.

If we flatten a subquery whose target list contains constants or
expressions, when those output columns are used in GROUPING SET columns,
the planner was capable of doing the wrong thing by merging a pulled-up
expression into the surrounding expression during const-simplification.
Then the late processing that attempts to match subexpressions to grouping
sets would fail to match those subexpressions to grouping sets, with the
effect that they'd not go to null when expected.

To fix, wrap such subquery outputs in PlaceHolderVars, ensuring that
they preserve their separate identity throughout the planner's expression
processing.  This is a bit of a band-aid, because the wrapper defeats
const-simplification even in places where it would be safe to allow.
But a nicer fix would likely be too invasive to back-patch, and the
consequences of the missed optimizations probably aren't large in most
cases.

Back-patch to 9.5 where grouping sets were introduced.

Heikki Linnakangas, with small mods and better test cases by me;
additional review by Andrew Gierth

Discussion: https://postgr.es/m/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi
src/backend/optimizer/prep/prepjointree.c
src/test/regress/expected/groupingsets.out
src/test/regress/sql/groupingsets.sql