Tom Lane wrote:
> Bruce Momjian <> writes:
> > Tom Lane wrote:
> >> I think it'd probably be better to just fix the rounding during display.
> > If we do that, should we remove some the existing JROUND calls in the
> > code?  I think we have to do this consistently, at least.
> Yeah, I was looking at that --- I think most if not all of the existing
> JROUND calls ought to go away.  Will try to work up a full patch over
> the weekend.


> > Also, I don't see how rounding is going to fix the problem that the
> > value is actually _rounded_ at different stages, meaning when you are
> > doing the output you don't know what came in, as outlined by my
> > timestamp_in data.
> I think the solution is that timestamp_out needs to decide how many
> fractional digits it wants to display, and then round off the input
> accordingly, *before* it breaks the input down into y/m/d/h/m/s fields.
> This "60.00" business is happening because the rounding is done only on
> the seconds-and-fractional-seconds field.

Well, the testing showed that the one with the most 9's was actually
rounded up to a whole number by timestamp_in, meaning we never have a
chance to adjust it in timestamp_out.  I am assuming you will be able to
round the middle test value up to a whole number in timestamp_out so the
60 number will disappear.

  Bruce Momjian                        |               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to