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 [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
