Re: ResultSet.getClob() causing problems when used with JPA's @Lob

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

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?

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.

For instance, we have pretty much similar problem with timestamp kind of
types: setTimestamp() does not say much if "with time zone" or "without
time zone" type should be used, so pgjdbc just sends a sting with
"oid.UNKNOWN" in a hope that backend will figure out the proper timestamp
type (luckily it can ignore time zone part when without time zone is
required).

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

Vladimir