Re: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: david(at)landgren(dot)net
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values
Date: 2019-03-07 19:53:19
Message-ID: 27557.1551988399@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I have encountered some counter-intuitive behaviour in upper_inf()

> select
> upper_inf('["2019-01-01",]'::daterange) as upper_null,
> upper_inf('["2019-01-01","2019-01-02"]'::daterange) as upper_valid,
> upper_inf('["2019-01-01",infinity]'::daterange) as upper_infinity;

> upper_null │ upper_valid │ upper_infinity
> ────────────┼─────────────┼────────────────
> t │ f │ f

> I would have expected ["2019-01-01",infinity] (upper_infinity above) to
> return true as well.

No; this is the intended and documented behavior, per the same
documentation section you quote,
https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-INFINITE

As shown in the examples there, a datatype value that happens to be
named "infinity" is just another value so far as the range mechanisms
are concerned, and there's a good reason for it: including or excluding
that value leads to valid but different ranges.

In hindsight, it was probably unwise to use "inf"/"infinite" as the
terminology for ranges; "unbounded" might've been less likely to
provoke confusion with datatypes that have values named "infinity".
But we're stuck with that naming now.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Julien Rouhaud 2019-03-07 20:58:03 Re: BUG #15669: Error with unnest in PG 11 (ERROR: 0A000)
Previous Message Tom Lane 2019-03-07 19:38:37 Re: BUG #15676: FOR UPDATE is not allowed with UNION ALL (and of course with UNION/INTERSECT/EXCEPT, DISTINCT?)