Vladimir Sitnikov schrieb am 29.07.2016 um 00:20:
>>other JDBC implementations.
>
> I've just looked into PgConnection.createClob, and it turns out the method is not implemented.
> This means no one ever used that to pass strings into large objects or whatever thing.
I noticed that as well. I wonder if we could use the PgStringClob and PgStringBlob I included with my patch for that
purpose?
I think the missing methods in those two classes shouldn't be that hard to implement.
> Large object API works with bytes, not characters, so I think we can
> safely assume that PgPreparedStatement.setClob results into string
> datatype (that is it should be just redirected to setString).
>
> This (plus the patch that enables to getClob for textual results) should solve the problem for the majority of pgjdbc
users.
>
> Thomas is that enough so you can give it a try?
Redirecting setClob() to setString() unconditionally would help us in the current migration, yes.
I can submit a patch for that, sounds easy enough.
> That's really a pity, because the (very unusual) handling of "large objects" makes the Clob/Blob handling quite
> incompatiable with other JDBC implementations.
>
> The problem with Blob remains (I'm not sure if you have one):
> postgresql cannot automatically create a large object when it receives "bytea" bind.
>
> The same "unknown" approach does not work here since "large objects" are stored aside and a colum contains just a
"oid"(64bit id).
>
> That adds yet another case "bytea vs large object" to
>
https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_features.md#binary-transfer-vs-exact-data-type
I still think that having a connection property that switches between large objects and bytea for BLOBs makes sense.
Thomas