| From: | Dennis Haney <davh(at)diku(dot)dk> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: IN joining | 
| Date: | 2004-03-05 21:32:03 | 
| Message-ID: | 4048F1D3.20405@diku.dk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Tom Lane wrote:
>Dennis Haney <davh(at)diku(dot)dk> writes:
>  
>
>>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}}.
>>    
>>
>
>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_IN handles
>             * RHS/LHS.
>             *
>             * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
>             * 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.
>  
>
Exactly my point... So why ever bother creating the {b,c} node which is 
legal by the above definition?
-- 
Dennis
use Inline C => q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-03-05 21:48:58 | Re: [HACKERS] Another crack at doing a Win32 | 
| Previous Message | Andrew Sullivan | 2004-03-05 21:08:26 | Re: 7.4.2 release notes |