Tom Lane wrote: <blockquote cite="mid11205.1078520699@sss.pgh.pa.us" type="cite"><pre wrap="">Dennis Haney <a
class="moz-txt-link-rfc2396E"href="mailto:davh@diku.dk"><davh@diku.dk></a> writes: </pre><blockquote
type="cite"><prewrap="">Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code
seems to also permit {{b,c},{a}}. </pre></blockquote><pre wrap="">
No, it does not --- as you say, that would give wrong answers. That
case is eliminated by the tests following this comment:
* JOIN_IN technique will work if outerrel includes LHS and * innerrel is exactly RHS; conversely
JOIN_REVERSE_INhandles * RHS/LHS. * * JOIN_UNIQUE_OUTER will work if outerrel is
exactlyRHS; * conversely JOIN_UNIQUE_INNER will work if innerrel is * exactly RHS.
Joining {b,c} to {a} does not meet any of those four allowed cases. </pre></blockquote> Exactly my point... So why ever
bothercreating the {b,c} node which is legal by the above definition?<br /><br /><br /><pre class="moz-signature"
cols="72">--
Dennis
use Inline C => q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
</pre>
