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