Re: BLOBs etc
От | Sven Köhler |
---|---|
Тема | Re: BLOBs etc |
Дата | |
Msg-id | 41DE0680.4030103@upb.de обсуждение исходный текст |
Ответ на | Re: BLOBs etc (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: BLOBs etc
|
Список | pgsql-jdbc |
>>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.
В списке pgsql-jdbc по дате отправления: