Re: BUG #14046: Bad mathematical rules for 0 cast - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #14046: Bad mathematical rules for 0 cast
Date
Msg-id CAKFQuwZj8a0ONkngoXhM_O23NaWBGSM0nihPDZKuhshKz8F-_g@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14046: Bad mathematical rules for 0 cast  (Jarosław Stokłosa <jaroslaw.stoklosa@nomino.pl>)
List pgsql-bugs
On Thu, Mar 31, 2016 at 12:49 AM, Jaros=C5=82aw Stok=C5=82osa <
jaroslaw.stoklosa@nomino.pl> wrote:

> You don't understand me. You give the examples differ than I - I've
> compared numbers with the same type, which are equal (IEEE 754, sign
> doesn't matter in this case for math equality). Cast to TEXT isn't able t=
o
> turn off equality, in my opinion.
>

=E2=80=8B-0 and +0 have distinct identities that are defined to compare as =
equal
when both values are represented as a floating point number.  While it may
be your opinion that said equality should hold after converting -0 and +0
to textual representations it is impossible to simultaneously maintain
their distinct identities post-text conversion and have their text
representations compare as equal.  PostgreSQL has chosen to treat their
identity characteristic as being primary and thus retains the + and - signs
when representing these values as text.

If there is anything more than your opinion of mathematical correctness
involved here it would be nice if you could share why it is you need the
float equality rules to continue to hold when two distinct floats are
represented as text.

In any case you can write a custom float-to-text function and use that
instead of "cast(float as text)"

David J.

pgsql-bugs by date:

Previous
From: Jarosław Stokłosa
Date:
Subject: Re: BUG #14046: Bad mathematical rules for 0 cast
Next
From: syspegasus@gmail.com
Date:
Subject: BUG #14058: Alternate storage path