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
reroutethe 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
supportstoring 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
anunconditional getClob() == getString() then people that actually need the distinction because they store large text
dataas "large objects" (oid columns): 

Thomas