Re: pg_locks needs a facelift

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> So I think we have to maintain the current arrangement
>> of one view, and add enough columns to it to handle all the
>> requirements.

> This seems perfectly ok...as long as there is 1:1 correspondence between
> locktag and lock for all present and future types of locks.  I'd like to
> point out though that when querying for user locks it's kind of nice not
> to wade through transaction locks, etc.

Well, sure, but that's what "SELECT ... WHERE" is for ;-)

> One nice things about the generic types (int4) is that they can be
> easily casted...if a column is displaying an xid that is not really an
> xid (user lock block offset), this can be annoying if you want to do
> some post query processing on the field, like bit shift it back into a
> 64 bit variable...especially since a dump/restore will drop all casts
> between two system provided columns.

The proposal I made was to display all fields of a USER lock as either
OID or int2, so you can certainly cast the OIDs to int4 if you want to
do some kind of arithmetic on them.
        regards, tom lane