]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Change post-rewriter representation of dropped columns in joinaliasvars.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Jul 2013 20:23:16 +0000 (16:23 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Jul 2013 20:23:16 +0000 (16:23 -0400)
commit04836087aab1500754a1de16744c4fcf8d4f0c5b
tree6e5e2173b5169a5b4bf88ed634fd95971cd4069e
parenta0dc92207a07262bb690836d8f061a66a5816a4d
Change post-rewriter representation of dropped columns in joinaliasvars.

It's possible to drop a column from an input table of a JOIN clause in a
view, if that column is nowhere actually referenced in the view.  But it
will still be there in the JOIN clause's joinaliasvars list.  We used to
replace such entries with NULL Const nodes, which is handy for generation
of RowExpr expansion of a whole-row reference to the view.  The trouble
with that is that it can't be distinguished from the situation after
subquery pull-up of a constant subquery output expression below the JOIN.
Instead, replace such joinaliasvars with null pointers (empty expression
trees), which can't be confused with pulled-up expressions.  expandRTE()
still emits the old convention, though, for convenience of RowExpr
generation and to reduce the risk of breaking extension code.

In HEAD and 9.3, this patch also fixes a problem with some new code in
ruleutils.c that was failing to cope with implicitly-casted joinaliasvars
entries, as per recent report from Feike Steenbergen.  That oversight was
because of an inadequate description of the data structure in parsenodes.h,
which I've now corrected.  There were some pre-existing oversights of the
same ilk elsewhere, which I believe are now all fixed.
src/backend/optimizer/util/var.c
src/backend/parser/parse_relation.c
src/backend/parser/parse_target.c
src/backend/rewrite/rewriteHandler.c
src/backend/utils/adt/ruleutils.c
src/include/nodes/parsenodes.h