Tom Lane wrote: > ITAGAKI Takahiro <itagaki.takah...@oss.ntt.co.jp> writes: > > We already have some codes to avoid -0 float8um (unary minus), > > but there are no protection in trunc(), ceil() and round() at least. > > I looked into the CVS history to find out when the anti-minus-zero code > got put into float8um. It seems to have been done by Tom Lockhart here: > > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/float.c.diff?r1=1.13;r2=1.14 > > The CVS commit message says > Check for zero in unary minus floating point code (IEEE allows an > explicit negative zero which looks ugly in a query result!). > along with some other unrelated changes. I can find no evidence in the > mailing list archives that there was any discussion about the point, > so I think Tom did that on his own authority. > > I'm of the opinion that minus zero was put into the IEEE floating point > standard by people who know a great deal more about the topic than > anyone on this list does, and that we do not have the expertise to be > second-guessing how it should work. Not long ago we took out code that > was interfering with spec-compliant treatment of IEEE infinity; I think > we should take out this code too. > > Yes, it will be platform dependent, because various platforms get the > IEEE spec wrong to some degree, but so what? This is hardly the only > platform dependence of that kind.
Agreed. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
