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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Prohibit row-security + inheritance in 9.4?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()