From: | Markus Schaber <schabi(at)logix-tt(dot)com> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | Ryan Li <rleeuk(at)yahoo(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: oid as long type |
Date: | 2006-02-08 17:34:43 |
Message-ID: | 43EA2BB3.1090607@logix-tt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Hi, Kris,
Kris Jurka wrote:
> The use of int is a historical artifact, but the problem is that we
> can't change the API without requiring clients to make code changes for
> some methods. We could add duplicate method signatures that take long
> for the oid types, but the problem is methods like LargeObject.getOID()
> and LargeObjectManager.create() return int and these cannot be changed
> to long without adjustments to the calling code. Additionally changes
> would be required to the fastpath infrastructure to send and receive
> longs which would be complicated by the fact that oids are really
> unsigned int4, not int8.
>
> So this is a known problem, but one we've generally avoided dealing with
> because few people actually bump into it. I suppose we could add the
> new method signatures and add new methods like getLongOID and only bail
> out when code called the old ones with values to be to be represented by
> an int. I'll put it on my todo list, but it's not real close to the top.
Maybe it would be possible to map it bit-wise to a singned int, so we
have negative OIDs on java side?
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Lewis | 2006-02-08 17:41:01 | Re: oid as long type |
Previous Message | Kris Jurka | 2006-02-08 17:19:03 | Re: oid as long type |