From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Bruno Wolff III <bruno(at)wolff(dot)to>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Jaime Casanova <systemguards(at)gmail(dot)com> |
Subject: | Re: someone working to add merge? |
Date: | 2005-11-22 20:38:53 |
Message-ID: | 20051122203853.GD99429@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 18, 2005 at 09:03:25PM +0100, Martijn van Oosterhout wrote:
> I'd say implement SQL MERGE which doesn't have any really unusual
> features. And seperately implement some kind of INSERT OR UPDATE which
> works only for a table with a primary key.
Is there any reeason this has to be a PK; shouldn't a unique index with
no nullable fields work just as well?
It seems bad to limit this to just a PK if we can avoid it. For example,
if you have something that's logging hits to web pages, you might have
this table:
CREATE TABLE url (
url_id serial PRIMARY KEY,
url text NOT NULL UNIQUE
);
I prefer having url_id as the PK because it's how you normally access
the table. But ISTM that there are cases where yo'd want to be able to
merge on two different sets of fields in one table, which is impossible
if we limit it to PK merges only.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-11-22 20:44:32 | Re: bind variables, soft vs hard parse |
Previous Message | Jim C. Nasby | 2005-11-22 20:30:45 | Re: MERGE vs REPLACE |