Re: JDBC driver's (non-)handling of InputStream:s - Mailing list pgsql-jdbc

From Peter Schuller
Subject Re: JDBC driver's (non-)handling of InputStream:s
Date
Msg-id 200403301248.09329.peter.schuller@infidyne.com
Whole thread Raw
In response to Re: JDBC driver's (non-)handling of InputStream:s  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: JDBC driver's (non-)handling of InputStream:s  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc
Hello,

> The short answer is no, it's not smart about InputStreams. It treats the
> stream essentially the same as if you'd read the entire stream into a
> byte array then called setBytes().

Ok. That's what I suspected. Thanks!

[ lots of interesting stuff snipped]

> You could use LOs instead of bytea if you have some flexibility in your
> schema; the LO interface should stream nicely. It's nastier to deal with
> LOs on the JDBC side, though: you'll need to drop the driver into a
> previous-version-compatibility mode (7.1?) or use the LO manager
> directly. Also LOs don't play well with autocommit.

Hmm, okay. So in versions greater than 7.1, I can not simply use a normal
PreparedStatement and setBinaryStream(), as suggested in the documentation?
Is this for some technical reason or is this method now deprecated?

I am only getting timeouts on postgresql.org at the moment, so perhaps this is
explicitly stated in the docs, but can I safely assume that any usage of the
Large Object Manager as part of a transactions whose queries are otherwise
done through normal JDBC channels, will not cause any interference between
the JDBC API and the LO manager? I.e., is it "safe" to intermix usage of
large objects with normal statements through JDBC?

--
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org


pgsql-jdbc by date:

Previous
From: Andrea Aime
Date:
Subject: Re: V3 protocol, batch statements and binary transfer
Next
From: Alan Stange
Date:
Subject: Re: V3 protocol, batch statements and binary transfer