From: | "olivier(dot)boissard(at)cerene(dot)fr" <olivier(dot)boissard(at)cerene(dot)fr> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL Admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: except command |
Date: | 2007-08-13 22:13:40 |
Message-ID: | 46C0D794.3020105@cerene.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Yes
I noticed It was not an ANSI sql operator
I think it's a good solution to spare temporay tables or result set
I was searching a way to ease some réplication scripts but I don't think
it will help me.
It's better to use it to get a couple of records inside complex queries
from many tables .
Thanks for help
Olivier
Kevin Grittner a écrit :
>>>> On Mon, Aug 13, 2007 at 4:30 PM, in message <46C0CD72(dot)5090407(at)cerene(dot)fr>,
>>>>
> "olivier(dot)boissard(at)cerene(dot)fr" <olivier(dot)boissard(at)cerene(dot)fr> wrote:
>
>> So it's like a filter on the first query
>>
>
> Exactly; I think that sums it up better than anything I said.
>
> By the way, it does strike me as an odd omission that there is no set
> operator in the ANSI standard to get you directly to the set of disjoint
> elements. With two datasets, a and b, you could always get there with:
>
> (a EXCEPT b) UNION ALL (b EXCEPT a)
>
> or with:
>
> (a UNION ALL b) EXCEPT (a INTERSECT b)
>
> Of course, you could store the sets in temporary tables to get there without
> generating from scratch each time, if that is expensive.
>
> -Kevin
>
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-08-13 22:37:54 | Re: postmaster.pid file |
Previous Message | Kevin Grittner | 2007-08-13 21:54:46 | Re: except command |