]> 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:48 +0000 (16:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 24 Mar 2012 20:21:48 +0000 (16:21 -0400)
commit811a2cbc167bfef4e5a88d468d5258385318ad87
treeb5183ea3ed8610ef888dd297fbab76ed9f5bd221
parenteca0c389f185b6bd76b4ca77195aa47d2e90dbb2
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