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                         [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to