]> git.ipfire.org Git - thirdparty/postgresql.git/commit
In back branches, fix conditions for pullup of FROM-less subqueries.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 15 Sep 2022 19:21:35 +0000 (15:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 15 Sep 2022 19:21:35 +0000 (15:21 -0400)
commit19a00ea56f67c40dbafdf1abb8ddbca026b72607
tree885ae6f025c3707be3aacd12306dfd525d696aa2
parentd4adff0e97f08fdb9e8844376419a271da7599ed
In back branches, fix conditions for pullup of FROM-less subqueries.

In branches before commit 4be058fe9, we have to prevent flattening
of subqueries with empty jointrees if the subqueries' output
columns might need to be wrapped in PlaceHolderVars.  That's
because the empty jointree would result in empty phrels for the
PlaceHolderVars, meaning we'd be unable to figure out where to
evaluate them.  However, we've failed to keep is_simple_subquery's
check for this hazard in sync with what pull_up_simple_subquery
actually does.  The former is checking "lowest_outer_join != NULL",
whereas the conditions pull_up_simple_subquery actually uses are

if (lowest_nulling_outer_join != NULL)
if (containing_appendrel != NULL)
if (parse->groupingSets)

So the outer-join test is overly conservative, while we missed out
checking for appendrels and groupingSets.  The appendrel omission
is harmless, because in that case we also check is_safe_append_member
which will also reject such subqueries.  The groupingSets omission
is a bug though, leading to assertion failures or planner errors
such as "variable not found in subplan target lists".

is_simple_subquery has access to none of the three variables used
in the correct tests, but its callers do, so I chose to have them
pass down a bool corresponding to the OR of these conditions.
(The need for duplicative conditions would be a maintenance
hazard in actively-developed code, but I'm not too concerned
about it in branches that have only ~ 1 year to live.)

Per bug #17614 from Wei Wei.  Patch v10 and v11 only, since we have a
better answer to this in v12 and later (indeed, the faulty check in
is_simple_subquery is gone entirely).

Discussion: https://postgr.es/m/17614-8ec20c85bdecaa2a@postgresql.org
src/backend/optimizer/prep/prepjointree.c
src/test/regress/expected/groupingsets.out
src/test/regress/sql/groupingsets.sql