From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 8.3 vs HEAD difference in Interval output? |
Date: | 2008-09-15 21:58:33 |
Message-ID: | 20219.1221515913@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2008-09-15 22:03:08 | Re: 8.3 vs HEAD difference in Interval output? |
Previous Message | Ron Mayer | 2008-09-15 21:48:41 | 8.3 vs HEAD difference in Interval output? |