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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Function trunc() behaves in unexpected manner with different data types
Дата
Msg-id AANLkTims8aP7sYZodksP+vjCyRnM_P8=CFBGBbQpQ_WT@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Function trunc() behaves in unexpected manner with different data types  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Function trunc() behaves in unexpected manner with different data types
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Function trunc() behaves in unexpected manner with different data types
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Corrupted index on 9.0.3 streaming hot standby