>>BTW: why don't getInputStream/getBLOB/... work for _both_, bytea and
>>oid? Shouldn't the JDBC driver be abled to determine the used datatype
>>and act accordingly? I'm sure you had you reasons. I'd just like to know
>>them.
>
> It certainly could do that. I'm guessing that it wasn't done to
> maintain symmetry with the set methods, knowing that only one can
> work. Making getInputStream work on oid would be easy, but making
> getBlob work on bytea would be more work to write a wrapper. There is
> also no real reason to use getBlob on bytea because no streaming is
> supported.
>
> Do you think the increased flexiblity is worth the potential for
> confusion when the corresponding set method doesn't work?
Ohh, well. The "getInputStream/getBLOB/..." above was ment to include
the set-Methods. After all you said, it seems reasonable not to
impelement set/getBlob() for bytea.
On the other hand, it may lower compatibility of the JDBC driver to
generic applications, if there is a datatype that either set/getBlob()
or set/getBinaryStream() doesn't work for. So one should avoid using bytea.
But am i right that set/getBinaryStream won't work for oid columns? I
think delegating set/getBinaryStream() to set/getBlob() is easy if the
JDBC driver would know when to do it. Would that be possible? That would
make oid columns the most compatible as thay would allow to use both:
the binarystream methods and the blob methods. The compatibility of the
JDBC could be improved by that.