Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal

> -----Original Message-----
> From: pgsql-jdbc-owner(at)postgresql(dot)org [mailto:pgsql-jdbc-
> owner(at)postgresql(dot)org] On Behalf Of Florent Guillaume
> Sent: Wednesday, September 12, 2012 9:36 AM
> To: Kevin Grittner
> Cc: DocSea - Patrice Delorme; pgsql-jdbc(at)postgresql(dot)org
> Subject: Re: [JDBC] Bug : FAST_NUMBER_FAILED when getting NaN on
> BigDecimal
>
> On Tue, Sep 11, 2012 at 4:10 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> > DocSea - Patrice Delorme <pdelorme(at)docsea(dot)com> wrote:
> >
> >> It is impossible to fetch data when numeric value in database is NaN
> >> It throws FAST_NUMBER_FAILED
> >> (postgresql-jdbc-9.1-902:AbstractJdbc2ResultSet:2176) because my
> >> value is not numeric (NaN).
> >> This is incorect behaviour since 'NaN' is a legal value in postgres
> >> for numeric type.
> >
> > How do you expect what you read to be represented in Java?
>
> java.lang.Double.NaN I guess.
>
>

I would think returning a special "Double" value when the expected datatype is "BigDecimal" would cause problems. I would expect it to return NULL since that is the closest you are going to get to the semantic meaning of NaN with the existing BigDecimal class.

Maybe someone would a add a class to the JDBC driver that is a sub-class of BigDecimal with infinity and NaN query/representation features but since BigDecimal does not have them, and for backwards compatibility number-to-BigDecimal has to remain, there really isn't any better option.

Well, there is one. If the driver returns NULL is these situations it could still maintain internally whether the NULL is the result of a conversion of INF/-INF/NaN or whether the NULL was in the data itself. The driver could expose a "isNaN(), isPosInf(), and isNegInf() methods that the user could query upon seeing a NULL BigDecimal so that it knows the "meaning" of the NULL. Backward compatibility only requires that the BigDecimal is still returned, new features can be added.

You either need to cast to a "float" in PostgreSQL so that the result is stored into a "Double" in Java or figure out some other application specific workaround.

David J.