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

Andreas Joseph Krogh <andreak@officenet.no> Tuesday 08 February 2011 12:34:19
> I hear over and over that PGs JDBC-driver wants to map CLOBs to OIDs but
> there really doesn't seem to be any good reasons for it (at least not that
> I can see). Why would I want to map my data as OID instead of varchar when
> the data is a JAVA-String? Is anyone using LO and the LO-api for storing
> large character-data? I think not. The @Lob annotation (which started this
> thread) is just there to help other DBs map the String-property correctly,
> I would love to get rid of it but need it to have my app work with Oracle.
> I also want other properties of varchar to work (LIKE-operator f.ex.,
> which Oracle also support on CLOBs), and I don't know what the PG-LO type
> supports. Honestly; I don't see any reason to use LOs at all, neither for
> BLOB (where I use bytea) or CLOBs (where I use varchar).

Actually there is good reason LOB are streamed. As it stands it's "large
object", and need special treatment. This LO can be 1,2 or 16GB. If you will
use bytea (it's impossible for such large objects) PGSQL sends all data in one
message so, select * my_table_with_los will end with OutOfMemory. 2nd reason
is that different communication is performed with LOBs, this is streaming
mode, which is faster so you will not OOM your JVM. You need to understand
that LO wasn't made to be something more then "fiele systems" in database for
realy big files.

CLOBS are more historical, in days of XMLs, but historical applications still
exists and sitll many systemes use plain flat files to exchange data.