Re: INTERVAL overflow detection is terribly broken - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: INTERVAL overflow detection is terribly broken
Date
Msg-id 20140128034816.GA30773@momjian.us
Whole thread Raw
In response to Re: INTERVAL overflow detection is terribly broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: INTERVAL overflow detection is terribly broken  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: jsonb and nested hstore
Next
From: Gavin Flower
Date:
Subject: Re: Fix comment typo in /src/backend/command/cluster.c