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

PostgreSQL doesn't have field type CLOB, nor BLOB.

If eveny it would be possible for driver to read CLOB from varchar, driver
will be unable to set proper value when calling UPDATE or INSTERT. It is due
to internal way how PSQL deals with those values.

I know drivers supports custom casting, but casting from varchar to clob is
implicite prohibted in JDBC. If you look at B-6 table x indicates possible
casting. There is no x, nor X on varchar cross clob

Kind regards,
Radosław Smogura

Andreas Joseph Krogh <andreak(at)officenet(dot)no> Monday 07 February 2011 21:50:10
> On 02/07/2011 09:11 AM, Radosław Smogura wrote:
> > Hi,
> > PGSQL doesn't have CLOB type, instead JDBC uses LOB, but PGSQL doesn't
>
> have
>
> > "clear" lob field type. It uses in table column with type OID, and
>
> supporting
>
> > table for storing large objects.
> >
> > Look at bug submited by me
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-4617
> > Should be fixed in 3.6.1 release.
>
> I'm experiencing this with 3.6.1 so whatever that issue fixes,
> MaterializedClobType (which is the default type Hibernate uses when it
> sees @Lob on String-types) still uses ClobTypeDescriptor, which again
> has this code:
>
> protected X doExtract(ResultSet rs, String name, WrapperOptions options)
> throws SQLException {
> return javaTypeDescriptor.wrap( rs.getClob( name ), options );
> }
>
> And it should be able to call rs.getClob().
>
> It's not clear to me why the JDBC-driver for PG shouldn't just use
> rs.getString() internally for getClob() calls? Requiring
> special-handling in Hibernate for dealing with Strings by setting an
> obscure property just doesn't seem right. And I don't want to set a
> property to handle CLOB which might affect how I use BLOBs.