Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
