]> granicus.if.org Git - postgresql/commit
Change post-rewriter representation of dropped columns in joinaliasvars.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Jul 2013 20:23:11 +0000 (16:23 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Jul 2013 20:23:11 +0000 (16:23 -0400)
commitc1f51ed2960ac2678535c252072695a4a8325a92
tree083b5eff82aeb87a4c2a801eeee304e5a6d4f5a8
parente23adeff0c288ff10a368b94cfb78ee291999113
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