Re: 8.3 vs HEAD difference in Interval output? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.3 vs HEAD difference in Interval output?
Date
Msg-id 20219.1221515913@sss.pgh.pa.us
Whole thread Raw
In response to 8.3 vs HEAD difference in Interval output?  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Responses Re: 8.3 vs HEAD difference in Interval output?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: 8.3 vs HEAD difference in Interval output?  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Unless I'm compiling stuff wrong, it seems HEAD is giving me
> slightly different output on Intervals than 8.3 in the roundoff
> of seconds.   8.3 was rounding to the nearest fraction of a second,
> HEAD seems to be truncating.

Yeah, that's surely because of the change to integer timestamps.

> Am I interpreting this right?  If so, shall I submit a patch
> that rounds it to hundredths of a second (hundredths seems
> hardcoded in the sprintf), or perhaps just silently add that
> fix to the EncodeInterval patch I'm doing any for SQL Standard
> and ISO intervals?

This is not the only place where the float-timestamps code has rounding
behavior that doesn't appear in the integer-timestamps code.  I don't
know if we want to buy into making them act the same ... after all,
if they acted exactly the same, we'd not have bothered with writing the
integer code.  In this example, rounding to hundredths doesn't seem like
a particularly good idea; it seems to me it should give you the exact
down-to-the-microsecond value.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: 8.3 vs HEAD difference in Interval output?
Next
From: "Kevin Grittner"
Date:
Subject: Re: 8.3 vs HEAD difference in Interval output?