The problem is that the OID type is ambiguous in postgres. Every table has
a column of OID type which is the internal row identifier. So the OID
really is an int, but when you want to use a large object, you set the type
of the LO column to be OID which becomes a pointer to the actual object
data. Then you can do setBytes or whatever in your interface to read or
write to the object. So he wants to leave it that the ResultSetMetaData
returns INTEGER as the type for oid.
They'd have to make a new pg datatype to store large objects that would
really just be another name for OID, but that would map to VARBINARY in the
metadata.
I don't know if they'll want to do that either...
-Nissim
-----Original Message-----
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000 3:00 PM
To: Turbine
Subject: Re: OID [was RE: postgres woes] Patch included
on 6/16/2000 11:53 AM, "Nissim Karpenstein" <[EMAIL PROTECTED]> wrote:
> This patch was rejected by the postgres team. Jon, what would you say to
> some hack code in village in the Column.typeEnum() that checks if the
> columnTypeName is oid then return VARBINARY otherwise return the
columnType?
> I'd prefer if they fix it in Postgres, but I think it might take a while.
>
> -Nissim
Uh. I'm not going to put this into Village when it is clearly a bug in their
code. This is something that people who use other databases shouldn't be
penalized for (an extra string comparison that only makes sense to Postgres)
by using Village.
Why was your patch rejected?
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
