Re: BLOBs etc

From: Sven Köhler <skoehler(at)upb(dot)de>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: BLOBs etc
Date: 2005-01-07 05:21:52
Message-ID: 41DE1C70.604@upb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

>>>The JDBC driver doesn't know what the target table looks like. It must
>>>blindly send data and hope it matches. This is why the set methods can
>>>only work for one type while the get methods could work for both.
>>
>>Is this going to be improved? Either by using serverside prepared
>>statements or by changing the server's bahaviour somehow?
>
> No, this was actually a design decision. It is possible to determine the
> expected data type in many cases, but the downside is that it requires a
> network roundtrip to the server. For simple statements this has the
> potential to nearly double execution time, so we don't want to do that.

I see the dilemma.

> Could we perhaps do this for prepared statements we expect to reuse? We
> could, but then you've introduced an odd inconsistency where sometimes
> things will work and sometimes they won't.

An inconsistency is not tolerable.

But still the postgresql server could accept the data generated by the
JDBC-driver's "setBinaryStream()" even for oid columns. Isn't that the
missing piece to make set/getBinaryStream() methods work for oid columns?

Is it known how other JDBC drivers handle this problems? Do they only
implements set/getBinaryStream() or set/getBlob()? I'd expect
set/getBinaryStream() to work at last, since it is the most simple way
to get the data. I don't want to bother you any longer, if other drivers
aren't any better, but it seems to me, like there's no unique way to get
binary data from a database via JDBC.

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2005-01-07 05:36:09 Re: BLOBs etc
Previous Message Kris Jurka 2005-01-07 04:41:49 Re: BLOBs etc