Re: Function trunc() behaves in unexpected manner with different data types

On Fri, Feb 25, 2011 at 9:48 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
>>
>>> 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=val + 1 where val = 2183.68;
>>
>> I think the mere idea of using floating point equality on a
>> WHERE clause is bogus, regardless of text or binary format.
>
> That's a bridge to[sic] far -- akin to saying floating point should not
> support equality operator.  select count(*) from foo where val >=
> 2183.68?  you are ok getting different answers depending on method of
> transmission of 2183.68 to the server?

I stand corrected -- I did some digging and Postgres's handling of
this issue is afaict correct: you are supposed to round on
presentation only, and equality matching on floating point in sql
(just like in C) is capricious exercise at best, at least without some
defenses. So, we can definitely file under 'not a bug'.

merlin