Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal - Mailing list pgsql-jdbc
From | Luis Flores |
---|---|
Subject | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal |
Date | |
Msg-id | CA+nXnG80Wfqt52krjQOUq3RjuXOkVf3Ju5z6S2WRM-RK0Cd1LQ@mail.gmail.com Whole thread Raw |
In response to | Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal ("David Johnston" <polobo@yahoo.com>) |
List | pgsql-jdbc |
Hello, All solutions seem to have a really negative side. My opinion is: Maintain default old behaviour (avoid break things ...) Create url property to enable new behavior (big_decimal_nan=true) Create new PgBigDecimal class extending BigDecimal, with constants for NaN, NEGATIVE_INFINITY and POSITIVE_INFINITY (these values can be created with new BigDecimal( BigInteger.valueOf( 0 ), 100 ), new BigDecimal( BigInteger.valueOf( 0 ), 101 ), new BigDecimal( BigInteger.valueOf( 0 ), 102 ) ) Override most BigDecimal's method to throw Exception or give correct results on operations with these constants and converting values from/to Double. For those worried about using 0^X for these constants, this operation new BigDecimal( BigInteger.valueOf( 0 ), 100 ).equals( new BigDecimal( 0 ) ) returns false, which is a good thing :) I believe this is the only correct manner to use NaN with Numeric value. It's easy for the programmer. Doesn't get confused with NULL values. Doesn't broke software. Luis Flores On Wed, Sep 12, 2012 at 4:02 PM, David Johnston <polobo@yahoo.com> wrote: >> -----Original Message----- >> From: Albe Laurenz [mailto:laurenz.albe@wien.gv.at] >> Sent: Wednesday, September 12, 2012 10:48 AM >> To: David Johnston *EXTERN*; Florent Guillaume; Kevin Grittner >> Cc: DocSea - Patrice Delorme; pgsql-jdbc@postgresql.org >> Subject: RE: [JDBC] Bug : FAST_NUMBER_FAILED when getting NaN on >> BigDecimal >> >> 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. >> > > OK. So the API would be more along the lines of: "if you are concerned with NaN/Infinity values you can poll the resultfirst to see if the returned value is valid or not. If the returned value is invalid and the user tries to read thevalue they get their exception. If the user sees that the value is invalid (from the polling) then they should foregoreading the value and instead interpret whatever invalid value is indicated. An actual NULL would be a valid value." > > I am unsure exactly WHEN the exception in this case is thrown but if too early then sub-classing BigDecimal is not possiblesince the exception would preclude the object ever being created (for backwards compatibility). > > Personally, I believe there needs to be some way to access this aspect of the PostgreSQL numeric type but it is not somethingthat, aside from a desire for completeness, currently affects me. Even a more fine-grained exception hierarchy(NaNException, PositiveInfinityException, NegativeInfinityException) that the user could catch on could be helpful(instead of having to perform string manipulation of the error message). In any cases a non-standard class wouldbe necessary so whether the driver provides ones or it simply provide information and requires the user to code whateverClass is appropriate is an explicit decision to make. > > David J. > > > > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
pgsql-jdbc by date: