]> 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:04 +0000 (16:23 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Jul 2013 20:23:52 +0000 (16:23 -0400)
commitb81d0691b9c6cc249511b92bb4b96f3a99a91eb0
tree675f35f9a5b3e0dbc200892e9de68e1f366c874d
parent5712eeb2e7cf8e4236acffd4a403e7f14a48866f
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
src/test/regress/expected/create_view.out
src/test/regress/sql/create_view.sql