> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
