From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Tjioe Ai Xin <xinxincute(at)gmail(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org, Oliver Jowett <oliver(at)opencloud(dot)com>, Kris Jurka <books(at)ejurka(dot)com> |
Subject: | Re: Can PostgreSQL do data type automated casting in |
Date: | 2005-11-25 13:16:04 |
Message-ID: | C09781BF-2612-445C-92D4-D77953CD8771@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
What we are supporting is setString will allow the backend to
determine the type of the input parameter if and only if you use
setString
Dave
On 25-Nov-05, at 2:03 AM, Tjioe Ai Xin wrote:
> Dear all,
>
> Does it mean in the future PostgreSQL JDBC Driver will support
> automated casting?
> So I don't have to write my code again in order to customize for
> new driver?
>
> Thanks in advance.
> Xin Xin
>
> --------------------------------------------------------------------
> On Friday 25 November 2005 04:20, Oliver Jowett wrote:
>> Dave Cramer wrote:
>>> You're on fairly shaky ground using "allowed by the spec" as
>>> justification.
>>
>> Why's that? Are we no longer trying to write a spec-compliant driver?
>>
>>> I'm thinking there are far more instances where people
>>> expect Oid unspecified to work than
>>> instances where they are going to change the type of the IN
>>> parameter
>>> in the same statement.
>>
>> Sure, but I'd rather not have an option that makes the driver break
>> unexpectedly. Given that we can have both unspecified string types
>> AND a
>> fix for the changing-type problem, why do you *not* want to do that?
>>
>> If you want a more "real world" example, how about something like
>> this:
>>
>>>> ArrayList toInsert = new ArrayList();
>>>> toInsert.add(new Integer(42));
>>>> toInsert.add(new Date());
>>>> toInsert.add("test string");
>>>> // ...
>>>> PreparedStatement ps = conn.prepareStatement("INSERT INTO
>>>> sometexttable(sometextcolumn) VALUES (CAST (? AS TEXT))");
>>>> for (Iterator i = toInsert.iterator(); i.hasNext(); ) {
>>>> ps.setObject(1, i.next());
>>>> ps.executeUpdate();
>>>> }
>>
>> Test cases are not meant to be real-world examples, they're test
>> code.
>> Use your imagination!
>>
>>> Given that the default behaviour adheres to the spec, I'm not too
>>> worried about the case below failing under these specific
>>> circumstances. I presume it passes with the 8.0,8.1 behaviour.
>>
>> It does.
>>
>> The code I have committed to CVS HEAD deals with the
>> changing-parameter-type case correctly even with
>> stringtype=unspecified,
>> anyway. Can you please try it out and see if you have any problems
>> with it?
>>
>> Otherwise, as far as I'm concerned I'm done with this -- if people
>> don't
>> want to change their (arguably broken) apps, they have an escape
>> hatch
>> they can enable explicitly or via compatible=7.4.. IMO we don't
>> need to
>> do anything more.
>>
>> -O
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2005-11-25 14:32:59 | Re: Log the sql query ? |
Previous Message | TNO | 2005-11-25 12:00:24 | Log the sql query ? |