From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kenneth Marshall <ktm(at)rice(dot)edu>, 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 21:23:03 |
Message-ID: | 48EE7637.6060101@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
Great.
> 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.
It looks to me that a double should be plenty to do
microseconds so long as we don't put big numbers into fsec.
printf("%.99f\n",59.111111111111111111);
59.11111111111111426907882 ...
Anyway - I'll try showing up-to-6-digits in both cases and
seeing if I can find a test case that breaks.
I guess this rounding trickiness with rounding explains some of
the bizarre code like this too:
#if 0
/* chop off trailing one to cope with interval rounding */
if (strcmp(str + len - 4, "0001") == 0)
{
len -= 4;
*(str + len) = '\0';
}
#endif
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-09 21:54:52 | Re: 8.3 vs HEAD difference in Interval output? |
Previous Message | Ryan Bradetich | 2008-10-09 20:54:45 | Re: [WIP] Reduce alignment requirements on 64-bit systems. |