Fix another cause of "wrong varnullingrels" planner failures.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 20 Jun 2023 15:09:56 +0000 (11:09 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 20 Jun 2023 15:09:56 +0000 (11:09 -0400)
commit3af87736bf5d5c7bea086d962afc2bbf4f29279a
tree2a123210172271066a9ec6fd25c6020e7a527315
parentefeb12ef0bfef0b5aa966a56bb4dbb1f936bda0c
Fix another cause of "wrong varnullingrels" planner failures.

I removed the delay_upper_joins mechanism in commit b448f1c8d,
reasoning that it was only needed when we have a single-table
(SELECT ... WHERE) as the immediate RHS child of a left join,
and we could get rid of that by hoisting the WHERE condition into
the parent join's quals.  However that new code missed a case:
we could have "foo LEFT JOIN ((SELECT ... WHERE) LEFT JOIN bar)",
and if the two left joins can be commuted then we now have the
problematic query shape.  We can fix this too easily enough,
by allowing the syntactically-lower left join to pass through
its parent qual location pointer recursively.  That lets
prepjointree.c discard the SELECT by temporarily hoisting the
WHERE condition into the ancestor join's qual.

Per bug #17978 from Zuming Jiang.

Discussion: https://postgr.es/m/17978-12f3d93a55297266@postgresql.org
src/backend/optimizer/prep/prepjointree.c
src/test/regress/expected/join.out
src/test/regress/sql/join.sql