Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
От | Tom Lane |
---|---|
Тема | Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 |
Дата | |
Msg-id | 6672.965667230@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: Re: [GENERAL] Trouble with float4 afterupgrading
from 6.5.3 to 7.0.2
|
Список | pgsql-hackers |
Philip Warner <pjw@rhyme.com.au> writes: > Now I understand, but it doesn't quite make sense given what was displayed. > The float4 value is *displayed* as 10.1, not 10.1000001, so I had assumed > that there was a level of either accuracy or display rouding happening. In float4-to-ASCII, yes. Modern printf implementations have some heuristics about the actual accuracy of float4 and float8 and where they ought to round off the printed result accordingly. But float4 to float8 is normally done just by appending zeroes to the mantissa. I suppose we could implement the conversion as "float8in(float4out(x))" instead of "(double) x" but it'd be several orders of magnitude slower, as well as being *less* useful to those who know what they're doing with float math (since the result would actually be a less-precise conversion except in cases where the intended value has a short decimal representation). After thinking about it some more, I'm of the opinion that the current behavior of float48eq and friends is the right thing, and that people who expect 10.1 to be an exact value should be told to use type NUMERIC. We should not kluge up the behavior of the float operations to try to make it look like inexact values are exact. That will just cause failures in other situations. regards, tom lane
В списке pgsql-hackers по дате отправления: