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.
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 |