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 | 123 +++++++++++++++++++++++------
src/backend/optimizer/prep/prepjointree.c | 19 ++++-
src/include/nodes/relation.h | 13 ++-
src/test/regress/expected/join.out | 47 +++++++++++
src/test/regress/sql/join.sql | 21 +++++
5 files changed, 191 insertions(+), 32 deletions(-)
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2012-03-26 01:47:30|
|Subject: pgsql: Replace empty locale name with implied value in CREATEDATABASE |
|Previous:||From: Tom Lane||Date: 2012-03-24 00:18:23|
|Subject: pgsql: Cast some printf arguments to avoid possibly-nonportablebehavio|