Re: [HACKERS] NAN code
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] NAN code |
Дата | |
Msg-id | m0zxD4C-000EBQC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] NAN code (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | 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@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: