Re: pg_locks needs a facelift

> In the earlier thread there was talk of separate views for system
> and user locks, but on reflection I think that's the wrong approach;
> principally because it will be impossible to get exactly-simultaneous
> snapshots of the system and user lock states if there are two views
> involved. And that's something you tend to want when studying lock
> behavior ;-). 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.

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.

What about having a view with all the generic columns and one
specialized view (pg_locks) for backwards compatibility?

Merlin