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 AANLkTims8aP7sYZodksP+vjCyRnM_P8=CFBGBbQpQ_WT@mail.gmail.com
Whole thread Raw
In response to Re: Function trunc() behaves in unexpected manner with different data types  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Function trunc() behaves in unexpected manner with different data types  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-bugs
On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
<alvherre@commandprompt.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. =A0The client has a similar issue though -- suppose it
>> fetches a value from the server and updates it back -- which record
>> gets the update? =A0You would get different results if the client was
>> using binary or text features of the protocol. =A0Not saying this is
>> wrong or needs to be fixed, just pointing it out :-).
>>
>> update foo set val=3Dval + 1 where val =3D 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 far -- akin to saying floating point should not
support equality operator.  select count(*) from foo where val >=3D
2183.68?  you are ok getting different answers depending on method of
transmission of 2183.68 to the server?

merlin

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Function trunc() behaves in unexpected manner with different data types
Next
From: Alvaro Herrera
Date:
Subject: Re: Corrupted index on 9.0.3 streaming hot standby