From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
Cc: | Kenneth Marshall <ktm(at)rice(dot)edu>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.3 vs HEAD difference in Interval output? |
Date: | 2008-10-09 21:54:52 |
Message-ID: | 10420.1223589292@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> Tom Lane wrote:
>> 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".
> If I understand the code right fsec should mostly be values
> between -1 and 1 anyway, because even in the floating point
> case seconds are carried in the tm->tm_sec part.
The problem is that that's a decomposed representation. In the stored
form, there's a floating-point seconds field that includes hours,
minutes, seconds, and fractional seconds, and therefore large values
of the H/M/S fields degrade the accuracy of the fraction part.
Here's an example (testing in 8.3, since HEAD defaults to integer):
regression=# select '1234567890 hours 0.123 sec'::interval;
interval
-------------------------
1234567890:00:00.123047
(1 row)
Since there's a (somewhat arbitrary) limitation of the hours to 2^31,
this is close to the worst possible case. (Hm, maybe someone actually
did the math and decided that 2 fractional digits were the most they
could promise given that? No, because this code dates from a time
when we included days in the same field too ... back then there might
have been no accuracy at all in the fraction part.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-10-09 21:57:06 | Re: head's linking problem |
Previous Message | Ron Mayer | 2008-10-09 21:23:03 | Re: 8.3 vs HEAD difference in Interval output? |