Re: someone working to add merge?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Bruno Wolff III <bruno(at)wolff(dot)to>, Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-15 23:09:03
Message-ID: 200511152309.jAFN93301069@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > This only happens because of the unique index. There's no predicate
> > locking involved. The btree code goes some lengths to make this work;
>
> That's one way to look at it; the other is to say that we have predicate
> locking for a very specific class of predicate, ie, equality of a
> unique key.
>
> In practice I think we only have a useful lock there for *primary* keys,
> because unique without NOT NULL doesn't actually constrain you to just
> one matching row ...

I agree --- an implementation that needs to use a table lock is useless,
and one with no primary key is too hard to implement and also near
useless.

I have update the TODO item to reflect this:

* Add MERGE command that does UPDATE/DELETE, or on failure, INSERT
(rules, triggers?)

To implement this cleanly requires that the table have a unique index
so duplicate checking can be easily performed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2005-11-15 23:11:46 Re: server closed connection on a select query
Previous Message Simon Riggs 2005-11-15 22:36:33 Re: [HACKERS] Per-table freeze limit proposal