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

Vladimir Sitnikov schrieb am 20.07.2016 um 15:52:
> 2)
> Thomas>I don't think checking the column type is necessary (at least not for me).
> Thomas>If this option is enabled, then all calls to getClob() are simply "re-routed" to getString().
>
> I'm afraid you miss the point.
>
> In postgresql world, there's "large object API": https://www.postgresql.org/docs/current/static/lo-interfaces.html
> pgjdbc wraps that, so if you have a column of "oid" type, then you can access the value via getClob and pgjdbc would reroute the calls to large object API.

I am aware of the large object API but for the intended use case of "treatClobAsString=true" this would simply not support storing string values through large objects - and I doubt that any project that would actually use "treatClobAsString=true" would mix CLOBs as "large objects" and CLOBs as "text".

> So getLong is not a mistake in getClob. getLong is here to retrieve the value of "large object oid" (i.e. pointer).
> That is why column type is crucial to tell if getClob is dealing with "large object API" or "just a string".

If we look at the use-case for this "override", I'm pretty sure there are (a lot) more people that could benefit from an unconditional getClob() == getString() then people that actually need the distinction because they store large text data as "large objects" (oid columns):

Thomas