]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Strip removed-relation references from PHVs in join clauses
authorRichard Guo <rguo@postgresql.org>
Wed, 15 Jul 2026 00:22:58 +0000 (09:22 +0900)
committerRichard Guo <rguo@postgresql.org>
Wed, 15 Jul 2026 00:22:58 +0000 (09:22 +0900)
commit18105e6db5e5314a575fdb23a99cf4809d8ef062
tree3b62e0e7ef43e34062360e71a52ed2a08b63a7b5
parentd1d9688b1f92590110cb868ce4f65f39da0af2a8
Strip removed-relation references from PHVs in join clauses

Commit 9a60f295b stripped the stale PlaceHolderVars left behind by
left-join removal from the surviving rels' baserestrictinfo and from
EquivalenceClass member expressions, but it overlooked join clauses.
A PlaceHolderVar embedded in a join clause can likewise retain the
removed rel and join in its phrels, since remove_rel_from_query()
fixes up the RestrictInfo's own relid sets but not the PHVs inside its
expression.

As before, this is normally harmless, because later processing
consults those relid sets rather than the embedded PHVs.  However, a
restriction clause derived from such an OR join clause inherits the
stale PlaceHolderVar, and when the derived clause is translated for an
appendrel child, pull_varnos() recomputes its relids and folds the
removed relation back in.  The rebuilt clause then references a
no-longer-existent relation, tripping an assertion during path
generation.

Fix by also stripping the removed relation from the PlaceHolderVars in
the surviving rels' join clauses, including the sub-clauses of any OR
clause.

Like 9a60f295b, this is only reachable on v18 and later, where
match_index_to_operand() began ignoring PlaceHolderVars.

Author: Arne Roland <arne.roland@malkut.net>
Reviewed-by: Tender Wang <tndrwang@gmail.com>
Reviewed-by: Richard Guo <guofenglinux@gmail.com>
Discussion: https://postgr.es/m/27a44087-3d65-473e-8d88-7c12228e0d7e@malkut.net
Backpatch-through: 18
src/backend/optimizer/plan/analyzejoins.c
src/test/regress/expected/join.out
src/test/regress/sql/join.sql