Re: Potential inconsistency in handling of timestamps - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: Potential inconsistency in handling of timestamps
Date
Msg-id 47211AA0.20102@opencloud.com
Whole thread Raw
In response to Re: Potential inconsistency in handling of timestamps  (Kris Jurka <books@ejurka.com>)
Responses Re: Potential inconsistency in handling of timestamps  (Kris Jurka <books@ejurka.com>)
List pgsql-jdbc
Kris Jurka wrote:
>
>
> On Fri, 26 Oct 2007, Oliver Jowett wrote:
>
>>> Null values should in theory get handled and returned well before
>>> TimestampUtils ever gets invoked (see
>>> AbstractJdbc2ResultSet.getTimestamp()). Can you supply a testcase
>>> demonstrating the problem?
>>
>> Actually, it looks like this was fixed in AbstractJdbc2ResultSet r1.95
>> (I was looking at CVS HEAD) but not on the 8.2 branch.
>>
>
> I don't follow.  The commit you mention was unify the handling of the
> RS.wasNull flag, not changing the handling of null values.  That should
> be caught in TimestampUtils.toTimestamp and friends.

Well, it did change getTimestamp() so it returns null sooner:


http://gborg.postgresql.org/cgi-bin/cvsweb.cgi/pgjdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java.diff?r1=1.94;r2=1.95;cvsroot=pgjdbc

@@ -419,7 +425,9 @@ public abstract class AbstractJdbc2Resul

      public Timestamp getTimestamp(int i, java.util.Calendar cal)
throws SQLException
      {
-        this.checkResultSet(i);
+        checkResultSet(i);
+        if (wasNullFlag)
+            return null;

          if (cal != null)
              cal = (Calendar)cal.clone();

You're right though, null should be caught by
TimestampUtils.toTimestamp() too.

Back to looking for a testcase?

-O

pgsql-jdbc by date:

Previous
From: "Brad Larson"
Date:
Subject: Calling a stored procedure with a custom return type
Next
From: Kris Jurka
Date:
Subject: Re: Potential inconsistency in handling of timestamps