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?  (Alex Hunsaker <badalex@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alex Hunsaker
Дата:
Сообщение: Re: Bad interval conversion?
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: Bad interval conversion?