> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-
> owner@postgresql.org] On Behalf Of Florent Guillaume
> Sent: Wednesday, September 12, 2012 9:36 AM
> To: Kevin Grittner
> Cc: DocSea - Patrice Delorme; pgsql-jdbc@postgresql.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.Grittner@wicourts.gov> wrote:
> > DocSea - Patrice Delorme <pdelorme@docsea.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
wouldexpect it to return NULL since that is the closest you are going to get to the semantic meaning of NaN with the
existingBigDecimal class.
Maybe someone would a add a class to the JDBC driver that is a sub-class of BigDecimal with infinity and NaN
query/representationfeatures but since BigDecimal does not have them, and for backwards compatibility
number-to-BigDecimalhas 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
isthe 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
beadded.
You either need to cast to a "float" in PostgreSQL so that the result is stored into a "Double" in Java or figure out
someother application specific workaround.
David J.