Re: [BUGS] BUG #1927: incorrect timestamp returned
| От | Bruce Momjian |
|---|---|
| Тема | Re: [BUGS] BUG #1927: incorrect timestamp returned |
| Дата | |
| Msg-id | 200510080246.j982kit00106@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #1927: incorrect timestamp returned (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [BUGS] BUG #1927: incorrect timestamp returned
|
| Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: