Fix incorrect handling of join clauses pushed into parameterized paths.
In some cases a clause attached to an outer join can be pushed down into
the outer join's RHS even though the clause is not degenerate --- this
can happen if we choose to make a parameterized path for the RHS. If
the clause ends up attached to a lower outer join, we'd misclassify it
as being a "join filter" not a plain "filter" condition at that node,
leading to wrong query results.
To fix, teach extract_actual_join_clauses to examine each join clause's
required_relids, not just its is_pushed_down flag. (The latter now
seems vestigial, or at least in need of rethinking, but we won't do
anything so invasive as redefining it in a bug-fix patch.)
This has been wrong since we introduced parameterized paths in 9.2,
though it's evidently hard to hit given the lack of previous reports.
The test case used here involves a lateral function call, and I think
that a lateral reference may be required to get the planner to select
a broken plan; though I wouldn't swear to that. In any case, even if
LATERAL is needed to trigger the bug, it still affects all supported
branches, so back-patch to all.
Per report from Andreas Karlsson. Thanks to Andrew Gierth for
preliminary investigation.
Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se
Branch
------
REL9_4_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/a347d5210ef0330b911e31c6249e4318d933b27b
Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 3 +++
src/backend/optimizer/util/restrictinfo.c | 11 ++++++++++-
src/include/optimizer/restrictinfo.h | 1 +
src/test/regress/expected/join.out | 27 +++++++++++++++++++++++++++
src/test/regress/sql/join.sql | 11 +++++++++++
5 files changed, 52 insertions(+), 1 deletion(-)