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_5_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e4e43a16b250abd9c4d3431d4824f7150ee74bec
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(-)
