Re: pg_locks needs a facelift

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> I don't like the idea of listing user locks with 'tuple' locks for no
> other reason than this might confuse what user locks are.

Fair enough, although I think that at least one major application of
user locks would be equivalent to tuple locks.  Somebody was asking
for named user locks in the previous thread, and the easiest way to
get that is to make a table containing just lock names, and then lock
on the CTIDs of that table.  Since there would be no reason to allow
UPDATE or DELETE in such a table, the putative instability of CTID
doesn't really matter.

However, displaying them as object locks certainly works, and you'd have
to put some intelligence in front of the view anyway about what meaning
you were assigning to user locks in your installation.  So you can
always cast to whatever you need.

> IMO, this is a problem with the current user lock module...it
> encourages locking over oid which is a bad practice.  A properly
> implemented user lock system would likely maintain a global sequence
> shared by all lockable objects, tuple or otherwise.

Certainly the current contrib/userlock code could stand a rewrite.
Or more likely, addition of new functions --- we should deprecate
the old ones, but I see no need to remove 'em right away.
        regards, tom lane