Re: problem with casts dump/restore

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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