Re: INTERVAL overflow detection is terribly broken

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Rok Kralj <rok(dot)kralj(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: INTERVAL overflow detection is terribly broken
Date: 2014-01-28 03:48:16
Message-ID: 20140128034816.GA30773@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Flower 2014-01-28 03:48:35 Re: Fix comment typo in /src/backend/command/cluster.c
Previous Message Andrew Dunstan 2014-01-28 03:43:01 Re: jsonb and nested hstore