Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have gone through the code and identified all the places that need
> > JROUND, basically places where we do complex calculations that include
> > fsec (fractional seconds).  This only affects timestamp=double backends,
> > not timestamp=int64.
> 
> I'm not sure I like this approach.  What you've essentially done is to
> remove any possibility of getting more than six digits of fractional
> precision out of a "double" timestamp --- and impose nontrivial
> calculation overhead to make sure that double doesn't have any extra
> precision.
> 
> 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.

Looking at the code, it seems JROUND() is used only in a few places:
        
        dt2time
        tm2interval
        time2t
        dt2local

What is the pattern on when to use it?

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (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 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to