Re: advisory locks (was: 8.2 beta blockers)

"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
> there are two things going on here: first, i think we are confusing
> the concepts of lockmode and waitmode, and secondly since in most
> other places wait locks are default with an optional nowait clause,
> how about make advisory locks follow a similar methodology?

I think *you* are confused about lockmode vs waitmode, but the patch is
not. The functions are

Name | Result data type | Argument data types | Description
pg_advisory_lock | void | bigint | obtain exclusive advisory lock
pg_advisory_lock_shared | void | bigint | obtain shared advisory lock
pg_try_advisory_lock | boolean | bigint | obtain exclusive advisory lock if available
pg_try_advisory_lock_shared | boolean | bigint | obtain shared advisory lock if available
pg_advisory_unlock | boolean | bigint | release exclusive advisory lock
pg_advisory_unlock_shared | boolean | bigint | release shared advisory lock

These also come in flavors taking 2 int4s, which is just a different way
of representing the locked object's identity, it's not different as far
as lock modes go. And there's

pg_advisory_unlock_all | void | | release all advisory locks

which comes in just one flavor.

I don't particularly care about "pg_try_advisory_lock" vs
"pg_advisory_lock_nowait", but it's not entirely obvious which modifier
to put first if we put them both on the end, ie is it
"pg_advisory_lock_shared_nowait" or "pg_advisory_lock_nowait_shared"?
Possibly the names are easier to remember as they are.

regards, tom lane