From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, Ryan Li <rleeuk(at)yahoo(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: oid as long type |
Date: | 2006-02-09 01:21:33 |
Message-ID: | 21986.1139448093@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Kris Jurka <books(at)ejurka(dot)com> writes:
> On Wed, 8 Feb 2006, Mark Lewis wrote:
>> To maintain compatibility with existing code but still give access to
>> the entire OID value space, why not map OID values >= 2**31 to negative
>> numbers-- i.e. just consider them to be signed ints?
> We don't always know when we're working with OIDs. If someone says
> PreparedStatement.setInt() we don't know if they're passing us a mangled
> OID they got from LargeObjectManager.create or if they're just passing us
> an int, so we'd have to send the mangled form to the database.
Does that matter? There's an implicit cast from int4 to oid on the
database side, so I am not clear where the problem really comes in.
regression=# select (-1)::int4::oid;
oid
------------
4294967295
(1 row)
regression=# select 4294967295::oid::int4;
int4
------
-1
(1 row)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2006-02-09 01:34:43 | Re: oid as long type |
Previous Message | Dave Cramer | 2006-02-09 01:15:11 | Re: PGobject returned from ResultSet.getObject |