Re: advisory locks (was: 8.2 beta blockers)

"Merlin Moncure" <mmoncure@gmail.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 |                  Descriptionpg_advisory_lock
          | void             | bigint              | obtain exclusive advisory lockpg_advisory_lock_shared       | void
           | bigint              | obtain shared advisory lockpg_try_advisory_lock          | boolean          | bigint
            | obtain exclusive advisory lock if availablepg_try_advisory_lock_shared   | boolean          | bigint
       | obtain shared advisory lock if availablepg_advisory_unlock            | boolean          | bigint
|release exclusive advisory lockpg_advisory_unlock_shared     | boolean          | bigint              | release shared
advisorylock
 

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