From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] NAN code |
Date: | 1999-01-04 16:41:19 |
Message-ID: | m0zxD4C-000EBQC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> > Seems that only isnan() is defined as part of Posix. But not
> > a definition that can force a NAN. So we have to find a
> > portable way to define the value NaN for double and float.
> > Does anybody know of such a way?
>
> See my later postings. 0.0/0.0 seems to do it.
Seen them. Just that I'm a little in doubt if this construct
couldn't generate a SIGFPE on all of our supported
platform/compiler combos. Still think we should add autoconf
stuff to search for a NAN definition and only fallback to the
above if that fails.
While searching for the NAN definition I've noticed too that
our float4/float8 datatypes can output 'NaN', but do not
parse them back. They simply elog(ERROR, ...) if you try to
use 'NaN' as an input string for a floating point attribute.
Shouldn't all input functions be able to parse back any
possible result of the corresponding output function? As of
now, I cannot imagine a construct (except a user defined C
function), that could result in a float8-NaN value stored in
the database. But as soon as it happens, the database
wouldn't any longer be dump/reloadable!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Hal Snyder | 1999-01-04 16:55:12 | 6.4.2? |
Previous Message | Thomas G. Lockhart | 1999-01-04 16:30:54 | Re: [HACKERS] NAN code |