diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-08-22 14:46:40 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-08-22 14:46:40 -0400 |
commit | de627adaad3a161b3ae0cafeb76c20519845799b (patch) | |
tree | 2c398e80300b55792ef393c79238ee7c1e1f6df3 /src/backend/executor/nodeHash.c | |
parent | 47de6ac11b53cf24393a2ef048f9e8921163da0a (diff) | |
download | postgresql-de627adaad3a161b3ae0cafeb76c20519845799b.tar.gz postgresql-de627adaad3a161b3ae0cafeb76c20519845799b.zip |
Avoid pushing quals down into sub-queries that have grouping sets.
The trouble with doing this is that an apparently-constant subquery
output column isn't really constant if it is a grouping column that
appears in only some of the grouping sets. A qual using such a
column would be subject to incorrect const-folding after push-down,
as seen in bug #16585 from Paul Sivash.
To fix, just disable qual pushdown altogether if the sub-query has
nonempty groupingSets. While we could imagine far less restrictive
solutions, there is not much point in working harder right now,
because subquery_planner() won't move HAVING clauses to WHERE within
such a subquery. If the qual stays in HAVING it's not going to be
a lot more useful than if we'd kept it at the outer level.
Having said that, this restriction could be removed if we used a
parsetree representation that distinguished such outputs from actual
constants, which is something I hope to do in future. Hence, make
the patch a minimal addition rather than integrating it more tightly
(e.g. by renumbering the existing items in subquery_is_pushdown_safe's
comment).
Back-patch to 9.5 where grouping sets were introduced.
Discussion: https://postgr.es/m/16585-9d8c340d23ade8c1@postgresql.org
Diffstat (limited to 'src/backend/executor/nodeHash.c')
0 files changed, 0 insertions, 0 deletions