Tom Lane wrote: > Bruce Momjian <email@example.com> 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.
OK > > 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 | http://candle.pha.pa.us firstname.lastname@example.org | (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