Re: IN joining
От | Dennis Haney |
---|---|
Тема | Re: IN joining |
Дата | |
Msg-id | 4048F1D3.20405@diku.dk обсуждение исходный текст |
Ответ на | Re: IN joining (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: IN joining
|
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: