Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal

> 
> You are right, as a matter of Fact BigDecimal does not support NaN like
> Double, Float does.
> However, postgres DOES support it and I find it disturbing that the driver
fails
> so badly without explaination (I had to dig in the driver source to find
out
> what the problem was).
> The problem is that somehow I managed to write my Double NaN to
> database but wasn't able to read it back even though I was using the very
> same driver in both cases!
> To me, behaviour is not coherent. Either wriiting of NaN is prevented or
> reading is functional !
> 
> Maybe a more explicit Exception like "numeric NaN values not supported"
> and not "org.postgresql.util.PSQLException: Bad value for type BigDecimal
:
> NaN;" which is rather obscure or to Extend BigDecimal with PgBigDecimal
that
> supports NaN (and infinity)...
> 

While I can understand the frustration the behavior is such because in the
vast majority of cases storing a double into a Postgres numeric is a
reasonable thing to do (and, from the driver's standpoint, maybe impossible
to detect with certainty anyway).  The driver assuming the user of
BigDecimal knows it cannot handle NaN is also not a bad assumption to make.
Wording could maybe be improved but it susiscently reports the problem
encountered (the database sent NaN and the BigDecimal had no idea what to do
with it.  It isn't like the driver has to know that NaN means Not-A-Number.
If the database sent along 'Pig' the same error would be generated but with
'Pig' instead of NaN.

Implicit conversions can and do cause problems.  That is what happened here.
As a user you should not have tried storing a Java Double into a Postgres
numeric but you should have converted it into a BigDecimal yourself.  If you
want consistent behavior that is exactly what you would have been forced to
do anyway.  Of course you or the driver could write a wrapper do that and
also check and report meaningful exceptions when the data and the target
type do not match - but given the open source nature of the driver and the
uncommon situation you presented, it is understandable that the behavior you
saw manifested itself.  No one else with the problem felt it was important
enough to fix.

David J.