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?
This is an awful hack, yes, but it might be better to see a strange-
looking OID but still be able to use it as a valid unique identifier
than to get a SQLException with no easy workaround.
In the long run it would probably be better to convert to longs, though.
Perhaps the migration pain could be mitigated by deprecating
LargeObject.getOID() in favor of LargeObject.getLongOID() or similar, so
at least new clients could work the right way.
-- Mark Lewis
On Wed, 2006-02-08 at 12:17 -0500, Kris Jurka wrote:
>
> On Wed, 8 Feb 2006, Ryan Li wrote:
>
> > What's the reason of using int rather than long for the large object
> > oid? I am experiencing a problem where the database server is generating
> > oids exceeding the size for a Java int, and got
> > "org.postgresql.util.PSQLException: Bad value for type int". Could this
> > be solve by making org.postgresql.largeobject.LargeObject.oid a long
> > type and make corresponding changes to the source tree?
> >
>
> 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.
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
