Re: Function trunc() behaves in unexpected manner with different data types - Mailing list pgsql-bugs

From Merlin Moncure
Subject Re: Function trunc() behaves in unexpected manner with different data types
Date
Msg-id AANLkTimeaNH81TemEzunroX6iotxpAceDFLMPY=7Lw12@mail.gmail.com
Whole thread Raw
In response to Re: Function trunc() behaves in unexpected manner with different data types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Function trunc() behaves in unexpected manner with different data types  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
On Fri, Feb 25, 2011 at 9:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> right -- in understand how floating point works -- but are you are
>> saying that you are ok with the fact that (for example) a table with a
>> floating point unique key could dump and not restore? more
>> specifically, a binary dump would restore but a text dump would not.
>
> pg_dump takes measures against that (see extra_float_digits).
>
>> I think this is a problem with our implementation -- not all versions
>> of 2183.68 as outputted from the server are the same internally.
>
> It's an inherent property of float math. =A0Yes, we could set the default
> value of extra_float_digits high enough that distinct internal values
> always had distinct text representations, but trust me, you would not
> like it.

no I wouldn't, and the pg_dump extra_float_digits setting addresses my
primary concern.  The client has a similar issue though -- suppose it
fetches a value from the server and updates it back -- which record
gets the update?  You would get different results if the client was
using binary or text features of the protocol.  Not saying this is
wrong or needs to be fixed, just pointing it out :-).

update foo set val=3Dval + 1 where val =3D 2183.68;

merlin

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Function trunc() behaves in unexpected manner with different data types
Next
From: Tom Lane
Date:
Subject: Re: BUG #5900: Coredump on executing query