I am using 7.2 and I need to write generic JDBC code, so I cannot use the
postgreSQL specific functions. I could use the "bytea" type, but it has
limitations and the ODBC driver does not handle it correctly.
The "standard" type for large objects is the "lo" type which is not
supported (bug?) by the latest stable 7.2 JDBC driver.
If declared, the "lo" type is reported as type 1111 (OTHER) by getTypeInfo
and getBytes() on it will return the 4 bytes (+1 for some reason) object id.
I wish there was a real standard for binary large objects with:
- standardization of the blob type name ("lo" is fine, but "blob" would
be better)
- type already defined in the database at creation (no need to create
the type manually)
- support in ODBC and JDBC of this type
- support for the JDBC getBlob, getBytes and getBinaryStream functions
(and corresponding setters)
- built-in vacuuming of blobs as part of the standard vacuuming
This would make it a lot easier... Maybe 7.3?
Benoit
----- Original Message -----
From: "Barry Lind" <barry@xythos.com>
To: "Benoit Menendez" <benoitm@pacbell.net>
Cc: <pgsql-jdbc@postgresql.org>
Sent: Tuesday, February 05, 2002 3:02 AM
Subject: Re: [JDBC] Blob support...
> Benoit,
>
> What version are you using? I would strongly recommend using the 7.2
> jdbc driver (it works fine against a 7.1 database). Also the 7.2 jdbc
> chapter of the documentation has examples on how to use both
> LargeObjects and bytea datatypes via jdbc.
>
> thanks,
> --Barry
>
>
> Benoit Menendez wrote:
> > I use both ODBC and JDBC to access the same database (from two different
> > applications) and I need blob support...
> >
> >
> >
> > I have created and used the "lo" type which is handled correctly by the
> > ODBC driver...
> >
> >
> >
> > But JDBC does not like the "lo" type for blobs...
> >
> >
> >
> > If I do a getBytes on an "lo" I only get 4 (+1) bytes...
> >
> >
> >
> > I tried "bytea" but ODBC does not work properly with this type...
> >
> >
> >
> > Is the "lo" type supported in a recent patch?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Benoit
> >
>
>