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

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

In response to

Responses

Browse pgsql-bugs by date

  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