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 по дате отправления: