Re: Problems with infinity - Mailing list pgsql-jdbc

On Mon, 17 Jan 2005, Oliver Siegmar wrote:

> Okay...then we cannot use Long.MAX_VALUE and Long.MIN_VALUE. I've
> searched for the nearest values to MAX/MIN which have
> hour/minute/second/millisecond set to 0. These are static finals within
> TimstampUtils now. Hope that's okay.
>
> For consistently you have to use it for Date _AND_ Timestamp.
>

OK, this patch looks good and complete, but I want to discuss this design
decision a little more, we seem to have lost the mailling list cc: in this
discussion, so I'm readding and summarizing.

The issue is that pg timestamps support values of +/- infinity which have
no equivalent in Java.  There was some code that tried to map these values
to pretty arbitrary date values which didn't really work and I removed
that and made the code throw an Exception when trying to call getTimestamp
on such a value.  Oliver Siegmar has found the need to use infinte values
in the database and access them from jdbc and has proposed readding
the mapping functionality and completing support for it.

The main issue is what value to map to, the original discussion for
timestamps was to use Long.MIN_VALUE / Long.MAX_VALUE when constructing
Timestamp objects.  I personally liked this idea, but then it starts to
get complicated when considering the date datatype as well.

Tom Lane weighed in noting that while the pg date datatype does not
currently support infinite values, but that is on the todo.

Oliver Siegmar also wanted to be able to call getDate() on an infinite
value timestams, but Long.MAX_VALUE is not a valid java.sql.Date value
because it has non-zero hour/minute/second components.  He proposed using
different constants in org.postgresql.jdbc2.TimestampUtils instead that
did have the zero hour/minute/second properties.

I personally like the "cleanliness" of Long.MAX_VALUE as it doesn't
require the pg jdbc driver to compile and just not supporting infinite
date values.  I don't feel that the backend todo is going to be completed
any time soon.

The counter argument is that eventually the todo item will be done and
that the supposed "cleanliness" is just an illusion because no other
database is going to allow you store a timestamp of Long.MAX_VALUE so
there is already an implicit assumption of using pg, why not make it
explicit?  Perhaps TimestampUtils isn't the place to put an end user
visible constant, but it should somewhere in the pg driver.

Thoughts?

Kris Jurka