Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.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
requiresthat the table have a unique index so duplicate checking can be easily performed.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
