Fix whole-row Var evaluation to cope with resjunk columns (again).
When a whole-row Var is reading the result of a subquery, we need it to
ignore any "resjunk" columns that the subquery might have evaluated for
GROUP BY or ORDER BY purposes. We've hacked this area before, in commit
68e40998d058c1f6662800a648ff1e1ce5d99cba, but that fix only covered
whole-row Vars of named composite types, not those of RECORD type; and it
was mighty klugy anyway, since it just assumed without checking that any
extra columns in the result must be resjunk. A proper fix requires getting
hold of the subquery's targetlist so we can actually see which columns are
resjunk (whereupon we can use a JunkFilter to get rid of them). So bite
the bullet and add some infrastructure to make that possible.
Per report from Andrew Dunstan and additional testing by Merlin Moncure.
Back-patch to all supported branches. In 8.3, also back-patch commit
292176a118da6979e5d368a4baf27f26896c99a5, which for some reason I had
not done at the time, but it's a prerequisite for this change.
src/backend/executor/execQual.c | 458 +++++++++++++++++++------------
src/backend/executor/execUtils.c | 4 +-
src/include/nodes/execnodes.h | 11 +
src/include/nodes/nodes.h | 1 +
src/test/regress/expected/subselect.out | 25 ++
src/test/regress/sql/subselect.sql | 9 +
6 files changed, 330 insertions(+), 178 deletions(-)
pgsql-committers by date
|Next:||From: Alvaro Herrera||Date: 2012-07-20 18:10:53|
|Subject: pgsql: connoinherit may be true only for CHECK constraints|
|Previous:||From: Robert Haas||Date: 2012-07-20 15:40:16|
|Subject: pgsql: Make new event trigger facility actually do something.|