Re: 'infinity'::Interval should be added - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 'infinity'::Interval should be added
Date
Msg-id 32446.1545098324@sss.pgh.pa.us
Whole thread Raw
In response to Re: 'infinity'::Interval should be added  (Isaac Morland <isaac.morland@gmail.com>)
List pgsql-hackers
Isaac Morland <isaac.morland@gmail.com> writes:
> On Mon, 17 Dec 2018 at 18:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> tl;dr: we should model it after the behavior of IEEE float infinities,
>> except we'll want to throw errors where those produce NaNs.

> Would it be OK to return NULL for ∞ - ∞?

IMO, no.  The only thing worse than inventing NaN for intervals would be
trying to use NULL as a substitute for it.  That'd amount to taking all
the semantic problems IEEE-arithmetic NaNs already have, and mixing
them irretrievably with SQL NULL's semantic problems (which are related
but different).

> Also am I right to assume that -infinity would use -INT_MAX, etc.? Or
> possibly -INT_MAX - 1?

The latter, which is why I mentioned INT_MIN.  There must not be any
finite value that would be less than -infinity, so if you don't use
INT_MIN for -infinity then you're just throwing away one useful
bitpattern.

(Conceivably, if we decided we did want NaN for intervals, we'd define
that as being INT_MIN and -infinity as being -INT_MAX.  But I really think
we don't want to go there, especially since we have not got NaN for
timestamps.  All these related datatypes need to be making similar
decisions, or we're just creating messy new edge cases.)

            regards, tom lane


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Fixing typos in tests of partition_info.sql
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: [suggestion]support UNICODE host variables in ECPG