Skip site navigation (1) Skip section navigation (2)

Re: Can PostgreSQL do data type automated casting in

From: Tjioe Ai Xin <xinxincute(at)gmail(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org, Oliver Jowett <oliver(at)opencloud(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Kris Jurka <books(at)ejurka(dot)com>
Subject: Re: Can PostgreSQL do data type automated casting in
Date: 2005-11-25 07:03:15
Message-ID: 200511251403.15562.xinxincute@gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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
> 

In response to

Responses

pgsql-jdbc by date

Next:From: TNODate: 2005-11-25 12:00:24
Subject: Log the sql query ?
Previous:From: Kris JurkaDate: 2005-11-25 05:57:25
Subject: Re: Again the JSCreator and Metadata issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group