From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, "Nathan M(dot) Davalos" <n(dot)davalos(at)sharedmarketing(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Function trunc() behaves in unexpected manner with different data types |
Date: | 2011-02-25 15:48:50 |
Message-ID: | AANLkTims8aP7sYZodksP+vjCyRnM_P8=CFBGBbQpQ_WT@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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 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?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-02-25 15:53:57 | Re: Corrupted index on 9.0.3 streaming hot standby |
Previous Message | Alvaro Herrera | 2011-02-25 15:40:09 | Re: Function trunc() behaves in unexpected manner with different data types |