Excerpts from Florian Pflug's message of sáb nov 27 01:29:39 -0300 2010:
> On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> > The problem with this idea is that it's not possible to implement it.
>
> How so? The implementation you proposed in your blog should work fine for this. XMAX_KEY_LOCK would signal that only
fieldsfrom set (B) are locked, while XMAX_SHARE_LOCK (or however thats called, didn't check the code) would signal that
allfields are locked. These are the only two field sets that we'd support, and for any set of columns the user
specifiedwe'd pick the smallest superset of the set we *do* support and use that (Thus, we obtain a key lock if only
fieldsfrom a unique index where specified, and a share lock otherwise).
>
> The only difference is that instead of presenting this to the user as an entirely new lock type, we instead present
itas a generalization of SHARE locks. The advantage being that *if* we ever figure out a way to support more
fine-grainedlocking of fields, (say, locking only the fields contain in some *specific* index, maybe by storing locking
theindex tuple), we can do so completely transparent to the user.
Oh, I see. Yeah, perhaps this could work. I'll have a look at both
ends.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
