| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "olivier(dot)boissard(at)cerene(dot)fr" <olivier(dot)boissard(at)cerene(dot)fr>, <pgsql-admin(at)postgresql(dot)org> |
| Cc: | "Steve Holdoway" <steve(dot)holdoway(at)firetrust(dot)com> |
| Subject: | Re: except command |
| Date: | 2007-08-13 21:54:46 |
| Message-ID: | 46C08CD6.EE98.0025.0@wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
>>> 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 | olivier.boissard@cerene.fr | 2007-08-13 22:13:40 | Re: except command |
| Previous Message | Tena Sakai | 2007-08-13 21:51:46 | postmaster.pid file |