Andrew Dunstan <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster