Re: INTERVAL overflow detection is terribly broken
От | Bruce Momjian |
---|---|
Тема | Re: INTERVAL overflow detection is terribly broken |
Дата | |
Msg-id | 20140130144214.GI2851@momjian.us обсуждение исходный текст |
Ответ на | Re: INTERVAL overflow detection is terribly broken (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Mon, Jan 27, 2014 at 10:48:16PM -0500, Bruce Momjian wrote: > On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX, > > > but I don't see it used anywhere else in our codebase. Is this OK? Is > > > there a better way? > > > > Most of the overflow tests in int.c and int8.c are coded to avoid relying > > on the MIN or MAX constants; which seemed like better style at the time. > > Yes, I looked at those but they seemed like overkill for interval. For > a case where there was an int64 multiplied by a double, then cast back > to an int64, I checked the double against INT64_MAX before casting to an > int64. > > > I'm not sure whether relying on INT64_MAX to exist is portable. > > The only use I found was in pgbench: > > #ifndef INT64_MAX > #define INT64_MAX INT64CONST(0x7FFFFFFFFFFFFFFF) > #endif > > so I have just added that to my patch, and INT64_MIN: > > #ifndef INT64_MIN > #define INT64_MIN (-INT64CONST(0x7FFFFFFFFFFFFFFF) - 1) > #endif > > This is only used for HAVE_INT64_TIMESTAMP. Adjusted patch applied for PG 9.4. Thanks for the report. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: