Re: Bad interval conversion?
От | Tom Lane |
---|---|
Тема | Re: Bad interval conversion? |
Дата | |
Msg-id | 26343.1250618844@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bad interval conversion? (Alex Hunsaker <badalex@gmail.com>) |
Ответы |
Re: Bad interval conversion?
|
Список | pgsql-bugs |
Alex Hunsaker <badalex@gmail.com> writes: > Ok well we can add overflow checks where we need-em. If you don't > think the attached patch is horridly ugly- im willing wade through the > uses of fsec and apply something similar where we need them. Throwing overflow errors doesn't seem very nice either, especially not for values that worked just fine before 8.4. I think the reason fsec_t is declared int32 is that it's expected to hold only *fractional* seconds, ie, not more than 1 million in the integer-timestamp world. The code snippets you point at are violating that assumption. Which is something the float code paths could get away with, but not so much for integer timestamps. Even if we widened the type to int64, it'd still mean that the overflow threshold is a factor of 1e6 closer in these code paths than in other places, and thus that there would still be values that failed in integer timestamp arithmetic but not float timestamp arithmetic. 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. regards, tom lane
В списке pgsql-bugs по дате отправления: