Re: Ding-dong, contrib is dead ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ding-dong, contrib is dead ...
Date
Msg-id 8510.1157479583@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ding-dong, contrib is dead ...  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: Ding-dong, contrib is dead ...  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Re: Ding-dong, contrib is dead ...  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
"Merlin Moncure" <mmoncure@gmail.com> 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)            waitvoid pg_advisory_lock_shared(int8)        waitbool
pg_try_advisory_lock(int8)           no waitbool pg_try_advisory_lock_shared(int8)        no waitbool
pg_advisory_unlock(int8)           returns T if successfulbool 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


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Ding-dong, contrib is dead ...
Next
From: Andrew - Supernews
Date:
Subject: Re: Ding-dong, contrib is dead ...