]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Further adjustments to PlaceHolderVar removal.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Aug 2015 18:13:39 +0000 (14:13 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Aug 2015 18:13:39 +0000 (14:13 -0400)
commit868bfd1f3db3f79d5f86577e3171fdff40ce21fe
tree3001300e5b03a86bdf910816b91b252f2c5fb4a6
parentde5edc660ae09e9a2785e52d2b539f2e0def1e63
Further adjustments to PlaceHolderVar removal.

A new test case from Andreas Seltenreich showed that we were still a bit
confused about removing PlaceHolderVars during join removal.  Specifically,
remove_rel_from_query would remove a PHV that was used only underneath
the removable join, even if the place where it's used was the join partner
relation and not the join clause being deleted.  This would lead to a
"too late to create a new PlaceHolderInfo" error later on.  We can defend
against that by checking ph_eval_at to see if the PHV could possibly be
getting used at some partner rel.

Also improve some nearby LATERAL-related logic.  I decided that the check
on ph_lateral needed to take precedence over the check on ph_needed, in
case there's a lateral reference underneath the join being considered.
(That may be impossible, but I'm not convinced of it, and it's easy enough
to defend against the case.)  Also, I realized that remove_rel_from_query's
logic for updating LateralJoinInfos is dead code, because we don't build
those at all until after join removal.

Back-patch to 9.3.  Previous versions didn't have the LATERAL issues, of
course, and they also didn't attempt to remove PlaceHolderInfos during join
removal.  (I'm starting to wonder if changing that was really such a great
idea.)
src/backend/optimizer/plan/analyzejoins.c
src/test/regress/expected/join.out
src/test/regress/sql/join.sql