Re: problem with casts dump/restore

> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > The reason why I did that to begin with was to be able to do some
> > in-query processing on a xid.  Is it intentional that oid has a
built in
> > cast to integer and xid does not?
>
> I'm not sure how intentional it is, but doing integer arithmetic on
XIDs
> seems pretty fraught with peril to me.  The comparison semantics on
XIDs
> are quite unlike normal integer comparisons.
>
>             regards, tom lane

Right.  Well, my reasons for doing this were pretty unusual.  I
'borrowed' the transaction column of pg_lock_status() so that it
returned the block# from the locktag.  Since this value for user locks
is application defined, it's natural to do something with it, bit
shifting it in this case.

I guess maybe this whole approach is a bad idea...maybe the best way to
return user lock information would be to make a separate function,
pg_user_lock_status() or something like that.  Anyways, thanks for
taking the time to look at it.

Merlin