On Fri, Feb 25, 2011 at 9:48 AM, Merlin Moncure wrote:
> On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
> 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 cl
On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
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
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 th
On Fri, Feb 25, 2011 at 9:21 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> right -- in understand how floating point works -- but are you are
>> saying that you are ok with the fact that (for example) a table with a
>> floating point unique key could dump and not restore? more
>> specifically,
Merlin Moncure writes:
> right -- in understand how floating point works -- but are you are
> saying that you are ok with the fact that (for example) a table with a
> floating point unique key could dump and not restore? more
> specifically, a binary dump would restore but a text dump would not.
On Thu, Feb 24, 2011 at 8:03 PM, Greg Stark wrote:
> On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote:
>> the root issue I think here is that the string version of the double
>> precision math is approximated:
>
> No, it's simpler than that, all double precision math is approximated.
> The r
On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote:
> the root issue I think here is that the string version of the double
> precision math is approximated:
No, it's simpler than that, all double precision math is approximated.
The root issue is that 2183.67 is not representable in a floating
On Thu, Feb 24, 2011 at 1:01 PM, Nathan M. Davalos
wrote:
> I ran into something interesting with using trunc() and different data
> types:
>
> The following is a simplified from the statement we’re using and produces
> the same results:
>
> select trunc( ((cast(2183.68 as numeric) - cast(1 as num
I ran into something interesting with using trunc() and different data
types:
The following is a simplified from the statement we're using and
produces the same results:
select trunc( ((cast(2183.68 as numeric) - cast(1 as numeric)) )*100)
/100
yields 2184.68
select trunc(((cast(2183.6
