Re: [BUGS] BUG #1609: Bug in interval datatype for 64 Bit timestamps

Tom Lane wrote:
> Oliver Siegmar <oliver(at)siegmar(dot)net> writes:
> > On Thursday 21 April 2005 15:57, Tom Lane wrote:
> >> If it is only the float case, some imprecision is to be expected.
>
> > So everything is okay?
>
> Well, it's not necessarily *wrong*, but maybe we could improve it.
> The code currently assumes it can print 10 fractional digits in the
> float case, which is overly optimistic once you get a large number
> of days in the "days" component. Maybe we should add some code
> to back off the precision depending on the number of days?

I decided to trim off just the last digit to show only 9 digits instead
of 10. The logic is that the last digit is giving us problems, and 9
digits is nano-second resolution, while 10 is 100 picoseconds, which is
kind of a weird default.

It does fix the problem:

test=> select '2005 years 4 mons 20 days 15 hours 57 mins 12.1 secs
ago'::interval;
interval
-------------------------------------------
-2005 years -4 mons -20 days -15:57:12.10
(1 row)

Doing like 200 days still shows the failure:

test=> select '2005 years 4 mons 200 days 15 hours 57 mins 12.1 secs
ago'::interval;
interval
---------------------------------------------------
-2005 years -4 mons -200 days -15:57:12.100000001
(1 row)

but I figure 20 days is much more common than 200.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073