Resurrect the "last ditch" code path in join_search_one_level().
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 15 Aug 2012 04:07:15 +0000 (00:07 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 15 Aug 2012 04:08:13 +0000 (00:08 -0400)
commiteb919e8fde4333d4a627d349a1460b07fc52dd3b
treed8aa60b1aea2d2c5c1902da144535a7842f2efdc
parent864de654c8271ab7f9fb8397fcc665ffed93645c
Resurrect the "last ditch" code path in join_search_one_level().

This essentially reverts commit e54b10a62db2991235fe800c629baef4531a6d67,
in which I'd decided that the "last ditch" join logic was useless.  The
folly of that is now exposed by a report from Pavel Stehule: although the
function should always find at least one join in a self-contained join
problem, it can still fail to do so in a sub-problem created by artificial
from_collapse_limit or join_collapse_limit constraints.  Adjust the
comments to describe this, and simplify the code a bit to match the new
coding of the earlier loop in the function.

I'm not terribly happy about this: I still subscribe to the opinion stated
in the previous commit message that the "last ditch" code can obscure logic
bugs elsewhere.  But the alternative seems to be to complicate the earlier
tests for does-this-relation-have-a-join-clause to the point where they can
tell whether the join clauses link outside the current join sub-problem.
And that looks messy, slow, and possibly a source of bugs in itself.
In any case, now is not the time to be inserting experimental code into
9.2, so let's just go back to the time-tested solution.
src/backend/optimizer/path/joinrels.c