"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I also agree with Andrew that pgfoundry is not a appropriate place for
> userlocks. They should be properly documented with a cleaned up api.
> I have no objection from them being removed from contrib in the short
> term due to the gpl issue, although I am not sure how you can
> copyright a function wrapper.
Right, I see the pgfoundry project as just a backwards-compatibility
thing for anyone who doesn't want to change their code. I'm happy to
put some cleaned-up functions into core right now (ie, for 8.2) if
someone will do the legwork to define and implement them.
After further thought it occurs to me that having both OID and int8
keys might be a problem, in that it's not too clear which you'd get
from a single-argument call. But we could offer just int8 and two-int4
signatures and rely on promoting OID to int8 if you need a lock on OID.
So the function list might look like
void pg_advisory_lock(int8) wait
void pg_advisory_lock_shared(int8) wait
bool pg_try_advisory_lock(int8) no wait
bool pg_try_advisory_lock_shared(int8) no wait
bool pg_advisory_unlock(int8) returns T if successful
bool pg_advisory_unlock_shared(int8) returns T if successful
plus all the above taking 2 int4's, plus
void pg_advisory_unlock_all()
Not wedded to these names at all...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
