From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | NaN behavior |
Date: | 2007-01-12 02:04:12 |
Message-ID: | 1168567452.5462.29.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
postgres=# select 'NaN'::numeric = 'NaN'::numeric,
'NaN'::float8 = 'NaN'::float8;
?column? | ?column?
----------+----------
t | t
(1 row)
This behavior is inconsistent with most people's notion of "NaN" -- in
particular, it is inconsistent with IEEE754. I can understand why
Postgres behaves this way, and we probably can't easily change it (if we
want to continue indexing NaN values, that is), but I think it should at
least be discussed in the documentation.
Comments? I'll write up a doc patch, barring any objections.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2007-01-12 02:07:38 | Re: PANIC: block 463 unfound during REDO after out of |
Previous Message | Alvaro Herrera | 2007-01-12 01:09:18 | Re: [HACKERS] unusual performance for vac following 8.2upgrade |
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-01-12 02:05:58 | Re: [PATCHES] Tablespace for temporary objects and sort files |
Previous Message | Simon Riggs | 2007-01-11 23:10:38 | Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off |