Re: [HACKERS] NAN code

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) #

In response to

Responses

Browse pgsql-hackers by date

  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