Skip site navigation (1) Skip section navigation (2)

Re: problem with casts dump/restore

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problem with casts dump/restore
Date: 2005-01-11 20:45:29
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A75A8@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> "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
> 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 HansenDate: 2005-01-11 20:48:28
Subject: Re: [HACKERS] problem with casts dump/restore
Previous:From: Marc G. FournierDate: 2005-01-11 20:15:41
Subject: PostgreSQL 8.0.0 Release Candidate 5

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group