Kevin Grittner wrote:
Kevin Grittner [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval(1);
interval
On Thu, Oct 09, 2008 at 11:50:17AM -0700, Ron Mayer wrote:
Kevin Grittner wrote:
Kevin Grittner [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days
Kenneth Marshall [EMAIL PROTECTED] writes:
There is a difference between the result 0.6 and 0.60 in rounding.
The first is accurate +-0.05 and the second is +-0.005. Certainly,
it does not seem unreasonable that machines can calulate intervals
to the nearest 100th of a second. What is not
On Thu, Oct 09, 2008 at 02:47:24PM -0500, Kevin Grittner wrote:
Kenneth Marshall [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days
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
Ron Mayer [EMAIL PROTECTED] 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.79 where it should be
1234567.8.
If I understand the code right fsec should mostly be values
between -1 and 1 anyway, because
Kenneth Marshall [EMAIL PROTECTED] wrote:
Even more surprising is the behavior for interval(1) here:
[ some context with nonsurprising examples removed ...]
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval(1);
interval
--
1
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] 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.79 ...
If I understand the code right [I didn't...]
The problem is ... seconds field that includes hours,
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.
In the psql output below it shows 8.3.1 outputting 6.70 secs
while the
Ron Mayer [EMAIL PROTECTED] 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
On Mon, Sep 15, 2008 at 4:58 PM, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Ron Mayer [EMAIL PROTECTED] 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
Kevin Grittner [EMAIL PROTECTED] wrote:
I find the results on 8.3.3 with integer timestamps surprising:
Even more surprising is the behavior for interval(1) here:
ccdev=# select '1 year 2 mons 3 days 04:05:06.64321'::interval;
interval
-
Kevin Grittner wrote:
...not the only place where the float-timestamps code has
rounding behavior that doesn't appear in the integer-timestamps
code. ...
I find the results on 8.3.3 with integer timestamps surprising:
Agreed it's surprising and agreed there are more places.
Sounds like I
Ron Mayer [EMAIL PROTECTED] writes:
Sounds like I should keep that separate and perhaps later
submit a separate patch to identify and/or remove surprising
rounding behavior.
Agreed. It's easier to review and get consensus on patches if you
keep separate issues separate.
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.
In the psql output below it shows 8.3.1 outputting 6.70 secs
while the
Tom Lane wrote:
This is not the only place where the float-timestamps code has rounding
behavior that doesn't appear in the integer-timestamps code.
Yeah... For that matter, I find this surprising as well:
regression=# select '0.7 secs'::interval, ('7 secs'::interval/10);
interval |
16 matches
Mail list logo