Antonin Houska <antonin.houska@gmail.com> writes:
> On 06/25/2013 10:00 PM, Tom Lane wrote:
>> After some contemplation, I think that the most practical way to fix
>> this is for deconstruct_recurse and distribute_qual_to_rels to
>> effectively move such a qual to the place where it logically belongs;
>> that is, rather than processing it when we look at the lower WHERE
>> clause, set it aside for a moment and then add it back when looking at
>> the ON clause of the appropriate outer join.
> Instead of setting it aside, can we (mis)use placeholder var (PHV), to
> ensure that the WHERE clause is evaluated below the OJ; instead of
> combining it with the ON clause?
No, that doesn't help; it has to be part of the joinquals at the join
node, or you don't get the right execution semantics. Plus you could
lose some optimization opportunities, for example if we fail to see
that there's a strict join clause associated with the outer join
(cf lhs_strict). Worse, I think wrapping a PHV around an otherwise
indexable clause would prevent using it for an indexscan.
> Whether I'm right or not, I seem to have found another problem while
> trying to enforce such a PHV:
> postgres=# SELECT i.*, j.* FROM i LEFT JOIN LATERAL (SELECT COALESCE(i)
> FROM j WHERE (i.n = j.n)) j ON true;
> The connection to the server was lost. Attempting reset: Failed.
[ pokes at that ... ] Hm, right offhand this seems like an independent
issue --- the ph_eval_at for the PHV is wrong AFAICS. Thanks for
reporting it!
regards, tom lane