> "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
> > cast to integer and xid does not?
> I'm not sure how intentional it is, but doing integer arithmetic on
> seems pretty fraught with peril to me. The comparison semantics on
> 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.
pgsql-hackers by date
|Next:||From: John Hansen||Date: 2005-01-11 20:48:28|
|Subject: Re: [HACKERS] problem with casts dump/restore|
|Previous:||From: Marc G. Fournier||Date: 2005-01-11 20:15:41|
|Subject: PostgreSQL 8.0.0 Release Candidate 5|