Re: Can PostgreSQL do data type automated casting in
От | Tjioe Ai Xin |
---|---|
Тема | Re: Can PostgreSQL do data type automated casting in |
Дата | |
Msg-id | 200511251403.15562.xinxincute@gmail.com обсуждение исходный текст |
Ответ на | Re: Can PostgreSQL do data type automated casting in (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Can PostgreSQL do data type automated casting in
(Dave Cramer <pg@fastcrypt.com>)
|
Список | 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 >
В списке pgsql-jdbc по дате отправления: