Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal
От | David Johnston |
---|---|
Тема | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal |
Дата | |
Msg-id | 032f01cd90f1$0d28d3f0$277a7bd0$@yahoo.com обсуждение исходный текст |
Ответ на | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal (Florent Guillaume <fg@nuxeo.com>) |
Ответы |
Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal
|
Список | pgsql-jdbc |
> -----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.
В списке pgsql-jdbc по дате отправления: