Re: BUG #14046: Bad mathematical rules for 0 cast

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jarosław Stokłosa <jaroslaw(dot)stoklosa(at)nomino(dot)pl>
Cc: John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14046: Bad mathematical rules for 0 cast
Date: 2016-03-30 16:32:11
Message-ID: 18628.1459355531@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?UTF-8?Q?Jaros=c5=82aw_Stok=c5=82osa?= <jaroslaw(dot)stoklosa(at)nomino(dot)pl> writes:
>> I humbly disagree with you. PostgreSQL use IEEE 754 for floating
>> point (mainly because that is what most - not all - computers today
>> use). IEEE 754 distinguishes +0 (or just 0) from -0. cast('-0' as
>> FLOAT) results in an IEEE 754 negative zero. Which is not identically
>> equal to a positive zero. The case to TEXT should, and does, preserve
>> this non-identical difference.

> I'm disagee with you. PostgreSQL don't distinguish +0 from -0 because
> cast('+0' as FLOAT) = cast('-0' as FLOAT) equals to TRUE. This is math
> rules. So case to float then to text shoud, and doesn't, preserve the
> equality. IEEE754 describes storage numbers in computer's memory but
> doesn't turn off math comparation rules.

Sorry, but that argument isn't terribly convincing. The point is exactly
whether casting to another type must preserve equality, and you're just
asserting that it should be so without providing any compelling reason.

There are plenty of other counterexamples to that, though. One that
comes to mind is that 42::numeric(6,3) will compare equal to
42::numeric(6,0), but if you cast them to text you will get '42.000'
and '42', which are not equal according to text's rules. Another is
that 'FOO' and 'foo' compare equal according to citext, but if you
cast them to text they aren't equal anymore.

Basically, different types are allowed to have different equality
behaviors. That's too useful to give up in the (vain) pursuit of
somebody's notion of mathematical purity.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Francisco Olarte 2016-03-30 17:42:29 Re: error to instaal PLTCL
Previous Message Tom Lane 2016-03-30 16:18:00 Re: BUG #14053: postgres crashes in plpgsql under load of concurrent transactions