Andrew Dunstan <andrew@dunslane.net> writes:
> It's a pity we didn't have Abhijit's patch 6 weeks ago.
Well, now that we have it, the question is whether we want to do
anything with it. One problem is it lacks documentation.
However, as I said, I'd really rather choose a new API altogether. The
main thing that seems to be lacking is a way to wait for a lock, rather
than having only the equivalent of ConditionalLockAcquire. Also I don't
much like exposing a LOCKMODE directly to user code --- to use
user_lock() or user_unlock() you have to put magic numbers into your SQL
code and hope nobody reassigns the C enum values in future releases.
I'd be inclined to just expose the notions of "share" and "exclusive"
lock and make these separate functions instead of magic numbers.
And then there's the question of what to expose in the way of lock
identifier options. What we've got now is "two int4's or an OID"
which seems a bit random, not to mention that the key space overlaps
in an undocumented fashion. Possibly we could offer OID, int8, or
two int4s, and modify the code to set locktag_field4 to distinguish
these cases so that the key spaces are independent.
I have no opinions about function names, except that I'd suggest
choosing names based around "advisory lock" instead of "user lock".
Advisory locks are a standard concept and so that terminology
already tells people something ...
regards, tom lane