Fix thinko in outer-join removal.

If we have a RestrictInfo that mentions both the removal-candidate
relation and the outer join's relid, then that is a pushed-down
condition not a join condition, so it should be grounds for deciding
that we can't remove the outer join.  In commit 2489d76c4, I'd blindly
included the OJ's relid into "joinrelids" as per the new standard
convention, but the checks of attr_needed and ph_needed should only
allow the join's input rels to be mentioned.

Having done that, the check for references in pushed-down quals
a few lines further down should be redundant.  I left it in place
as an Assert, though.

While researching this I happened across a couple of comments that
worried about the effects of update_placeholder_eval_levels.
That's gone as of b448f1c8d, so we can remove some worry.

Per bug #17769 from Robins Tharakan.  The submitted test case
triggers this more or less accidentally because we flatten out
a LATERAL sub-select after we've done join strength reduction;
if we did that in the other order, this problem would be masked
because the outer join would get simplified to an inner join.
To ensure that the committed test case will continue to test
what it means to even if we make that happen someday, use a
test clause involving COALESCE(), which will prevent us from
using it to do join strength reduction.

Patch by me, but thanks to Richard Guo for initial investigation.

Discussion: https://postgr.es/m/17769-e4f7a5c9d84a80a7@postgresql.org

1 files changed, 0 insertions, 10 deletions

diff --git a/src/backend/optimizer/util/var.c b/src/backend/optimizer/util/var.c
index 8c9824e54d6..c55c5f805b3 100644
--- a/src/backend/optimizer/util/var.c
+++ b/src/backend/optimizer/util/var.c
@@ -198,16 +198,6 @@ pull_varnos_walker(Node *node, pull_varnos_context *context)
 			 * fall back to the conservative assumption that the PHV will be
 			 * evaluated at its syntactic level (phv->phrels).
 			 *
-			 * There is a second hazard: this code is also used to examine
-			 * qual clauses during deconstruct_jointree, when we may have a
-			 * PlaceHolderInfo but its ph_eval_at value is not yet final, so
-			 * that theoretically we could obtain a relid set that's smaller
-			 * than we'd see later on.  That should never happen though,
-			 * because we deconstruct the jointree working upwards.  Any outer
-			 * join that forces delay of evaluation of a given qual clause
-			 * will be processed before we examine that clause here, so the
-			 * ph_eval_at value should have been updated to include it.
-			 *
 			 * Another problem is that a PlaceHolderVar can appear in quals or
 			 * tlists that have been translated for use in a child appendrel.
 			 * Typically such a PHV is a parameter expression sourced by some