Re: Bad interval conversion?
От | Alex Hunsaker |
---|---|
Тема | Re: Bad interval conversion? |
Дата | |
Msg-id | 34d269d40908181236j36ce90ffo959d9c0c87f6519e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bad interval conversion? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bad interval conversion?
Re: Bad interval conversion? |
Список | pgsql-bugs |
On Tue, Aug 18, 2009 at 12:07, Tom Lane<tgl@sss.pgh.pa.us> wrote: > Throwing overflow errors doesn't seem very nice either, especially not > for values that worked just fine before 8.4. I just checked both 8.3.7 and 8.2.13 give: # select '4817191.623 ms'::interval; interval ------------------ -00:35:47.483648 (1 row) > Seems like a proper fix would involve doing some modulo arithmetic to be > sure that we add the integral seconds to the seconds field and only a > fraction to the fsec field. Ok I looked around at the other fsec assignments in adt/ and did not see any that were not treating them as fractional correctly. This seems to be the only case. Anywho is the below more what you expected? (I decided to do it for the floating point case as well...) With this patch I get (it also passes a make check): # select '4817191.623 ms'::interval; interval ----------------- 01:20:17.191623 *** a/src/backend/utils/adt/datetime.c --- b/src/backend/utils/adt/datetime.c *************** *** 2986,2991 **** DecodeInterval(char **field, int *ftype, int nf, int range, --- 2986,2994 ---- break; case DTK_MILLISEC: + tm->tm_sec += val / 1000; + val = val % 1000; + #ifdef HAVE_INT64_TIMESTAMP *fsec += rint((val + fval) * 1000); #else
Вложения
В списке pgsql-bugs по дате отправления: