]> granicus.if.org Git - postgresql/commit
Flatten join alias Vars before pulling up targetlist items from a subquery.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 22 Nov 2013 19:37:38 +0000 (14:37 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 22 Nov 2013 19:37:38 +0000 (14:37 -0500)
commit122ba5dadf93c04d29828c9e533938e9b0ca31a7
treeafcfcab1dc032f0dc23d346ab66aa79c19fca90e
parent6765a2c96af49dbbd5391804100cae5eedadb94b
Flatten join alias Vars before pulling up targetlist items from a subquery.

pullup_replace_vars()'s decisions about whether a pulled-up replacement
expression needs to be wrapped in a PlaceHolderVar depend on the assumption
that what looks like a Var behaves like a Var.  However, if the Var is a
join alias reference, later flattening of join aliases might replace the
Var with something that's not a Var at all, and should have been wrapped.

To fix, do a forcible pass of flatten_join_alias_vars() on the subquery
targetlist before we start to copy items out of it.  We'll re-run that
processing on the pulled-up expressions later, but that's harmless.

Per report from Ken Tanzer; the added regression test case is based on his
example.  This bug has been there since the PlaceHolderVar mechanism was
invented, but has escaped detection because the circumstances that trigger
it are fairly narrow.  You need a flattenable query underneath an outer
join, which contains another flattenable query inside a join of its own,
with a dangerous expression (a constant or something else non-strict)
in that one's targetlist.

Having seen this, I'm wondering if it wouldn't be prudent to do all
alias-variable flattening earlier, perhaps even in the rewriter.
But that would probably not be a back-patchable change.
src/backend/optimizer/prep/prepjointree.c
src/backend/optimizer/util/var.c
src/test/regress/expected/join.out
src/test/regress/sql/join.sql