Re: Can PostgreSQL do data type automated casting in

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
>