]> granicus.if.org Git - postgresql/commit
Fix planner's handling of outer PlaceHolderVars within subqueries.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Mar 2012 20:21:39 +0000 (16:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Mar 2012 20:21:39 +0000 (16:21 -0400)
commit8279eb4191c7ab9920c72ec8eec5df0e7b8c7530
tree7b8c98f6b214bd4017d517a86ea5ea2b9a65f93b
parented61127be483d8939e13a151773549f1517d6e67
Fix planner's handling of outer PlaceHolderVars within subqueries.

For some reason, in the original coding of the PlaceHolderVar mechanism
I had supposed that PlaceHolderVars couldn't propagate into subqueries.
That is of course entirely possible.  When it happens, we need to treat
an outer-level PlaceHolderVar much like an outer Var or Aggref, that is
SS_replace_correlation_vars() needs to replace the PlaceHolderVar with
a Param, and then when building the finished SubPlan we have to provide
the PlaceHolderVar expression as an actual parameter for the SubPlan.
The handling of the contained expression is a bit delicate but it can be
treated exactly like an Aggref's expression.

In addition to the missing logic in subselect.c, prepjointree.c was failing
to search subqueries for PlaceHolderVars that need their relids adjusted
during subquery pullup.  It looks like everyplace else that touches
PlaceHolderVars got it right, though.

Per report from Mark Murawski.  In 9.1 and HEAD, queries affected by this
oversight would fail with "ERROR: Upper-level PlaceHolderVar found where
not expected".  But in 9.0 and 8.4, you'd silently get possibly-wrong
answers, since the value transmitted into the subquery wouldn't go to null
when it should.
src/backend/optimizer/plan/subselect.c
src/backend/optimizer/prep/prepjointree.c
src/include/nodes/relation.h
src/test/regress/expected/join.out
src/test/regress/sql/join.sql