From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kenneth Marshall <ktm(at)rice(dot)edu> |
Cc: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kevin Grittner <Kgrittn(dot)CCAP(dot)Courts(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.3 vs HEAD difference in Interval output? |
Date: | 2008-10-09 19:42:47 |
Message-ID: | 4323.1223581367@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kenneth Marshall <ktm(at)rice(dot)edu> writes:
> There is a difference between the result 0.6 and 0.60 in rounding.
> The first is accurate +-0.05 and the second is +-0.005. Certainly,
> it does not seem unreasonable that machines can calulate intervals
> to the nearest 100th of a second. What is not clear to me is how the
> decision to stop at the 2nd decimal digit was reached.
Probably by flipping a coin ;-). You have to remember that all this
behavior was designed around floating-point intervals, so there's
inherent imprecision in there; and the extent depends on the size of
the interval which makes it pretty hard to choose a display precision.
In the integer-timestamp world we know that the number is exact in
microseconds. We clearly ought to be prepared to display up to six
fractional digits, but suppressing trailing zeroes in that seems
appropriate.
We could try to do the same in the float case, but I'm a bit worried
about finding ourselves showing "1234567.799999" where it should be
"1234567.8".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2008-10-09 19:47:24 | Re: 8.3 vs HEAD difference in Interval output? |
Previous Message | Kenneth Marshall | 2008-10-09 19:14:37 | Re: 8.3 vs HEAD difference in Interval output? |