Re: [INTERFACES] Trouble with JDBC2 ResultSet.getDate() - Mailing list pgsql-jdbc
From | Palle Girgensohn |
---|---|
Subject | Re: [INTERFACES] Trouble with JDBC2 ResultSet.getDate() |
Date | |
Msg-id | 3AF7FFBF.75E49B06@partitur.se Whole thread Raw |
In response to | Trouble with JDBC2 ResultSet.getDate() (Juhan-Peep Ernits <juhan@cc.ioc.ee>) |
Responses |
Re: Re: [INTERFACES] Trouble with JDBC2 ResultSet.getDate()
Re: Re: [INTERFACES] Trouble with JDBC2 ResultSet.getDate() Re: Re: [INTERFACES] Trouble with JDBC2 ResultSet.getDate() |
List | pgsql-jdbc |
Hi! I just got bitten by this too. I use type timestamp in the database, and often need the latest timestamp, but want to format it as a date. With 7.0.x, I just select ts from foo order by ts desc limit 1 and in java: d = res.getDate(1); but this fails everywhere in my code now :( The problem is this optimization in src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java, introduced in 1.21: @@ -418,12 +418,8 @@ String s = getString(columnIndex); if(s==null) return null; - SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd"); - try { - return new java.sql.Date(df.parse(s).getTime()); - } catch (ParseException e) { - throw new PSQLException("postgresql.res.baddate",new Integer(e.getErrorOffset()),s); - } + + return java.sql.Date.valueOf(s); } /** Log string is: - Removed need for SimpleDateFormat in ResultSet.getDate() improving performance. I cannot find any reference to whether it is bad or not to let getDate return a date when the string from postgres is a timestamp or datetime. It appears to me as a good feature, and since it has been working for quite som time, and the postgres documenation recommends timestamp as the best time & date type, is it really necessary to break functionality for many users this way? The performance fix is good, but I think code shall be added to make it backward compatible. My query will need to be rewritten like this: select ts::date as d, ts from foo order by ts desc limit 1 and I have hundreds of them :( Maybe we can introduce a try-catch clause to handle the case where the string is really a timestamp and not a pure date, but this would give users the false impression that everything is OK, and exceptions are really a performance hog... Maybe just check if the string size is > 10, and then use the old code? Agree, this would make it complicated. /Palle Juhan-Peep Ernits wrote: > > System is Debian "woody" > java is IBM SDK1.3 > Source is CVS from March 20, 2001. > > Trouble is the following, that > > org.postgresql.jdbc2.ResultSet.getDate(int) > > Started to generate errors > > java.lang.NumberFormatException: 15 14:25:17+02 > at java.lang.Integer.parseInt(Integer.java:415) > at java.lang.Integer.parseInt(Integer.java:455) > at java.sql.Date.valueOf(Date.java:97) > at org.postgresql.jdbc2.ResultSet.getDate(ResultSet.java:427) > at org.postgresql.jdbc2.ResultSet.getDate(ResultSet.java:665) > ... > > when fetching dates from fields of timestamp > type. It seems that the fixes provided in CVS version 1.18 from Jan 24 > 23:41:04 2001 of ResultSet.java regarding getDate() method broke it for > our application. Now I went back to 1.17 and copied the > > SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd"); > > try { > return new java.sql.Date(df.parse(s).getTime()); > } catch (ParseException e) { > throw new PSQLException("postgresql.res.baddate",new > Integer(e.getErrorOffset()),s); > } > > part to replace the new code: > > return java.sql.Date.valueOf(s); > > and it works fine but I have not had time to debug this any further. May > be it would be nice to have that part of the old code included in the 7.1 > release driver? > > Regards, > > Juhan Ernits > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl -- Partitur Informationsteknik AB Wenner-Gren Center +46 8 566 280 02 113 46 Stockholm +46 70 785 86 02 Sweden girgen@partitur.se
pgsql-jdbc by date: