Re: Re: [GENERAL] +/- Inf for float8's
| От | Thomas Lockhart |
|---|---|
| Тема | Re: Re: [GENERAL] +/- Inf for float8's |
| Дата | |
| Msg-id | 3B1C4CD8.4301C97C@fourpalms.org обсуждение исходный текст |
| Ответ на | Re: Re: [GENERAL] +/- Inf for float8's (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: Re: [GENERAL] +/- Inf for float8's
|
| Список | pgsql-hackers |
> > -infinity < normal values < infinity < NaN < NULL
> I was thinking about making NaN equivalent to NULL. That would give
> consistency in ordering, and probably also in arithmetic. Additionally,
> if the platform supports it we ought to make the Invalid Operation FP
> exception (which yields NaN) configurable: either get NULL or get an
> error.
I'd like to see the distinction between NaN and NULL retained, since the
two "values" arise from different circumstances and under different
conditions. If a particular app needs them to be equivalent, then that
is easy enough to do with SQL or triggers.
- Thomas
On a modestly related note, I'm come over to the notion that the
date/time value 'current' could be ripped out eventually. Tom, isn't
that the only case for those types which bolluxes up caching of
date/time types?
В списке pgsql-hackers по дате отправления: