Re: 8.3 vs HEAD difference in Interval output?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, "Kenneth Marshall" <ktm(at)rice(dot)edu>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: 8.3 vs HEAD difference in Interval output?
Date: 2008-10-09 19:47:24
Message-ID: 48EE197C.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Kenneth Marshall <ktm(at)rice(dot)edu> 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 year 2 mons 3 days 04:05:06.60
>>> (1 row)
>>> That trailing zero should be considered a bug.

> What is not clear to me is how the
> decision to stop at the 2nd decimal digit was reached.

See this posting and others on the thread:

http://archives.postgresql.org/pgsql-hackers/2008-09/msg00999.php

The current rules seem to be:

(1) If precision is specified, round to that precision.

(2) If result has only zeros in the fraction, show no fraction, else
show at least two digits in the fraction, adding a trailing zero if
needed to get to two digits, but don't show any trailing zeros in the
fraction beyond the second position.

I think it would be ideal if we could track how many digits of
accuracy we have in a value, and show them all, even if that involves
trailing zeros. If that's not feasible, let's consistently not show
trailing zeros. Rounding .64 to .6 and then showing .60 is just plain
wrong.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-10-09 19:57:38 Re: [WIP] plpgsql is not translate-aware
Previous Message Tom Lane 2008-10-09 19:42:47 Re: 8.3 vs HEAD difference in Interval output?