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 по дате отправления: