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

From: Andreas Joseph Krogh <andreak(at)officenet(dot)no>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: ResultSet.getClob() causing problems when used with JPA's @Lob
Date: 2011-02-08 14:32:33
Message-ID: 18903054.82.1297175554326.JavaMail.on@prod2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

På tirsdag 08. februar 2011 kl 14:25:18 skrev "Oliver Jowett" <oliver(at)opencloud(dot)com>:
> Andreas Joseph Krogh wrote:
> > På tirsdag 08. februar 2011 kl 13:31:21 skrev du:
> >> Andreas Joseph Krogh wrote:
> >>
> >>> ...but the StringClobType is deprecated.
> >> The obvious question here is "why?"
> >
> > I totally agree that Hibernate is not behaving as it should when encountering a String property annotated with @Lob. I just wanted to shed some light on what rational PG has for implementing setClob() as it is and not just as a wrapper for setString.
>
> My point about the "why?" is that there was presumably some reason why
> it is deprecated and investigating what that reason is may be enlightening.
>
> > If I get it right the justification for it being as it is is not to break old apps, in case they use OID for large character types of data and not varchar or text. I would be very surprised if any such applications still exist...
>
> Well, it's also arguably a more natural mapping of the CLOB type (go and
> read the javadoc at
> http://download.oracle.com/javase/6/docs/api/java/sql/Clob.html; for
> "logical pointer" read "OID" and you essentially have the postgres
> implementation right there)
>
> It's been this way for ages with no problems, it's a reasonable
> spec-compliant implementation, so you need a good argument for changing
> it now. Your argument doesn't seem to go beyond "it doesn't do this
> non-standard thing I want it to do" which is not very convincing to me.

To me the whole CLOB type seems to be superfluous and only exists to satisfy RDBMS-vendors with broken(...) implementations of varchar/text-types. CLOBs really shouldn't be necessary these days. PG can and does better by allowing arbitrary length of text stored in varchar/text-columns. Feel free to disagree.

> If you do think it's useful to change then you need to discuss it with
> Kris since he's basically looking after the driver solo these days (I
> unfortunately have no time to spend on the driver any more, and even
> this list discussion has eaten up all my JDBC time for about the next
> month). I anticipate he'll be worried about breaking compatibility so
> you'll need a good argument there.

I don't feel I'm in the position to push a new implementation of CLOB in the PG-JDBC-driver forward and don't want to waste anyones time any more on this issue.

But - having this discussion has shed some light on the issue and might be useful for archiving purpose if the CLOB issue some day resurrects.

--
Andreas Joseph Krogh <andreak(at)officenet(dot)no>
Senior Software Developer / CTO
Public key: http://home.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Trollåsen | somebody else doing it wrong, without |
NORWAY | comment. |
Org.nr: NO 981 479 076 | |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+

Browse pgsql-jdbc by date

  From Date Subject
Next Message Florian Weimer 2011-02-08 14:55:11 Connecting over UNIX domain sockets
Previous Message Oliver Jowett 2011-02-08 12:31:21 Re: ResultSet.getClob() causing problems when used with JPA's @Lob