Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal
От | Albe Laurenz |
---|---|
Тема | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal |
Дата | |
Msg-id | D960CB61B694CF459DCFB4B0128514C2086259D3@exadv11.host.magwien.gv.at обсуждение исходный текст |
Ответ на | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal ("David Johnston" <polobo@yahoo.com>) |
Ответы |
Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal
|
Список | pgsql-jdbc |
David Johnston wrote: >>>> It is impossible to fetch data when numeric value in database is NaN >>> How do you expect what you read to be represented in Java? >> java.lang.Double.NaN I guess. > 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. I don't think that's a good idea. Apart from the fact that a null pointer isn't a good representation for an out-of-bounds value, that would change the behaviour and might break applications that expect the current behaviour. I think it is OK to throw an exception if a value cannot be represented, but it should be a meaningful message. Yours, Laurenz Albe
В списке pgsql-jdbc по дате отправления: