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 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 > +1
Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers