Re: blob without largeobject api - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: blob without largeobject api
Date
Msg-id 4072A183.6030802@opencloud.com
Whole thread Raw
In response to Re: blob without largeobject api  (Edoardo Ceccarelli <eddy@axa.it>)
Responses Re: blob without largeobject api  (Markus Schaber <schabios@logi-track.com>)
List pgsql-jdbc
Edoardo Ceccarelli wrote:
> Tried with a driver downloaded from http://jdbc.postgresql.org/
>
> pg74.213.jdbc3.jar
>
> the result is always the same:
> java.lang.ClassCastException: com.caucho.sql.UserConnection
> on row:
> LargeObjectManager lom =
> ((org.postgresql.PGConnection)db).getLargeObjectAPI();

Ok, this means your pooling implementation is not using the postgresql
driver's PooledConnection to generate the proxy connections to hand out,
but is implementing them itself (using instances of
com.caucho.sql.UserConnection, it appears). So you won't be able to get
at postgresql-specific interfaces with that pooling implementation,
regardless of what the driver does.

> I think that the second suggestion is about using a "standard" way to
> save a blob field, I have tried something like this:
> - insert record without blob
> - open record for update and use setBytes() to save blob data
> having some minor problems so far but I'd like to know if this is the
> right way to do it.

That's the basic idea, although there's no real need to separate the
insert and update. With compatible=7.1 in effect, setBytes() becomes
"create an appropriate LO and set the parameter to the new OID". The
main gotcha is that you must wrap any queries that deal with LOs in a
transaction; autocommit won't work. You'll also need a mechanism to
clean up LOs that no longer have references to them in the main DB (I
think there might be something in contrib/ to do this?)

-O

pgsql-jdbc by date:

Previous
From: Edoardo Ceccarelli
Date:
Subject: Re: blob without largeobject api
Next
From: "David Wall"
Date:
Subject: Re: blob without largeobject api