Re: Potential inconsistency in handling of timestamps
От | Oliver Jowett |
---|---|
Тема | Re: Potential inconsistency in handling of timestamps |
Дата | |
Msg-id | 47211AA0.20102@opencloud.com обсуждение исходный текст |
Ответ на | Re: Potential inconsistency in handling of timestamps (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: Potential inconsistency in handling of timestamps
|
Список | 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 по дате отправления: