Tom Lane wrote:
> ITAGAKI Takahiro <itagaki.takahiro@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +