Re: [HACKERS] JPA + enum == Exception - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: [HACKERS] JPA + enum == Exception
Date
Msg-id 22027.1360684244@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] JPA + enum == Exception  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] JPA + enum == Exception  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-jdbc
Craig Ringer <craig@2ndquadrant.com> writes:
> On 02/08/2013 12:55 PM, Tom Lane wrote:
>> AFAIK this is just business as usual with JDBC: setString() implies that
>> the parameter is of a string type.

> Well, it means that it's a type compatible with a java.lang.String .
> JDBC doesn't say much about the database-side type.

> It's my strong view that we should accept setString(...) for any
> string-like type, like xml, json, domains of text, and so on - or at
> least provide an easy, no-superuser-required way to tell Pg to do so.

The difficulty I've got with that is that there are only two kinds of
literal in SQL, namely numbers and strings, so that "it looks like a
string" applies to absolutely every non-numeric type.  If we go down
this road we'll end up allowing implicit casts from text to (at least)
every non-numeric type, which will be pretty much fatal for type
checking purposes.

IIRC, there's already a hack to tell the JDBC driver to mark setString
parameters as "unknown" rather than "text", which seems to me to be
a much less dangerous way of getting the lenient behavior when you want
it.

            regards, tom lane


pgsql-jdbc by date:

Previous
From: Andreas Reichel
Date:
Subject: Re: Timestamp vs. Java Date/Timestamp
Next
From: Bryan Varner
Date:
Subject: Re: PostgreSQL XAResource & GlassFish 3.1.2.2