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
