Re: Can PostgreSQL do data type automated casting in

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
>