Re: INTERVAL overflow detection is terribly broken
От | Bruce Momjian |
---|---|
Тема | Re: INTERVAL overflow detection is terribly broken |
Дата | |
Msg-id | 20140128034816.GA30773@momjian.us обсуждение исходный текст |
Ответ на | Re: INTERVAL overflow detection is terribly broken (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: INTERVAL overflow detection is terribly broken
|
Список | pgsql-hackers |
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: