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