Re: Re: [GENERAL] +/- Inf for float8's
От | Peter Eisentraut |
---|---|
Тема | Re: Re: [GENERAL] +/- Inf for float8's |
Дата | |
Msg-id | Pine.LNX.4.21.0008172109490.346-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] +/- Inf for float8's ("Ross J. Reedstrom" <reedstrm@rice.edu>) |
Ответы |
Re: Re: [GENERAL] +/- Inf for float8's
|
Список | pgsql-hackers |
(Side note: Folks, we need a real bug/issue-tracking system. We just discussed this a month ago ("How PostgreSQL's floating point hurts everyone everywhere"). If anyone's interested in porting Bugzilla or some other such system to PostgreSQL and putting it into use, let me know.) Ross J. Reedstrom writes: > Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be > pretty simple: the #define is already there: UNSAFE_FLOATS. Define that, > and the CheckFloat[48]Val functions just return true. Show me a system where it doesn't work and we'll get it to work. UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour; it intends to speed things up, not make things portable. > > NULL and NaN are not quite the same thing imho. If we are allowing NaN > > in columns, then it is *known* to be NaN. > > For the purposes of ordering, however, they are very similar. Then we can also treat them similar, i.e. sort them all last or all first. If you have NaN's in your data you wouldn't be interested in ordering anyway. > we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word > for those three values), else elog(). "non-finite values" Side note 2: The paper "How Java's floating point hurts everyone everywhere" provides for good context reading. Side note 3: Once you read that paper you will agree that using floating point with Postgres is completely insane as long as the FE/BE protocol is text-based. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: