On Thu, Jan 13, 2011 at 23:58, Alvaro Herrera
> It goes like this: instead of acquiring a shared lock on the involved
> tuple, we only acquire a "key lock", that is, something that prevents
> the tuple from going away entirely but not from updating fields that are
> not covered by any unique index.
> As discussed, this is still more restrictive than necessary (we could
> lock only those columns that are involved in the foreign key being
> checked), but that has all sorts of implementation level problems, so we
> settled for this, which is still much better than the current state of
Seems to me that you can go a bit further without much trouble, if you
only consider indexes that *can* be referenced by foreign keys --
indexes that don't have expressions or predicates.
I frequently create unique indexes on (lower(name)) where I want
case-insensitive unique indexes, or use predicates like WHERE
deleted=false to allow duplicates after deleting the old item.
So, instead of:
you can write:
&& indexInfo->ii_Expressions == NIL
&& indexInfo->ii_Predicate == NIL)
This would slightly simplify RelationGetIndexAttrBitmap() because you
no longer have to worry about including columns that are part of index
I guess rd_uindexattr should be renamed to something like
rd_keyindexattr or rd_keyattr.
Is this worthwhile? I can write and submit a patch if it sounds good.
In response to
pgsql-hackers by date
|Next:||From: Marti Raudsepp||Date: 2011-01-28 20:48:54|
|Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR
|Previous:||From: Robert Haas||Date: 2011-01-28 20:39:33|
|Subject: Re: FPI|