Re: [BUGS] BUG #4660: float functions return -0

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)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.

regards, tom lane