From: | "Mason Hale" <masonhale(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2739: INTERSECT ALL not working |
Date: | 2006-11-06 19:57:01 |
Message-ID: | 8bca3aa10611061157p2f523447o8a45e8bf7304d25a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom -
Many thanks for the quick reply. I feel honored to receive email from you
after seeing your name so many times in my web searches on Postgres topics.
That's not how I understood INTERSECT ALL to work. But it's the clear the
spec is right and my understanding is wrong.
This is not a bug.
Unfortunately the INTERSECT ALL as spec'd and implemented doesn't quite give
me what I need. So back to the drawing board for me...
best regards,
Mason
On 11/6/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Mason Hale" <masonhale(at)gmail(dot)com> writes:
> > The query below should return 10 rows,
>
> Not by my reading of the spec. SQL92 7.10 saith:
>
> b) If a set operator is specified, then the result of applying
> the set operator is a table containing the following rows:
>
> i) Let R be a row that is a duplicate of some row in T1 or
> of
> some row in T2 or both. Let m be the number of duplicates
> of R in T1 and let n be the number of duplicates of R in
> T2, where m >= 0 and n >= 0.
>
> ...
>
> iii) If ALL is specified, then
>
> ...
>
>
> 3) If INTERSECT is specified, then the number of
> duplicates
> of R that T contains is the minimum of m and n.
>
> You have m = 1, n = 2 for each distinct row at the INTERSECT step,
> ergo you get one copy out.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-11-06 20:53:28 | Re: Operator Classes and ANALYZE |
Previous Message | Tom Lane | 2006-11-06 19:03:29 | Re: BUG #2739: INTERSECT ALL not working |