"Merlin Moncure" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
