Обсуждение: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values

The following bug has been logged on the website:

Bug reference:      15675
Logged by:          David Landgren
Email address:      david@landgren.net
PostgreSQL version: 10.3
Operating system:   Linux
Description:

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. In fact, I could argue that it should be the only case
where it returns true. Or at the least, that
upper_inf('["2019-01-01",]'::daterange) return null.

Using an alternative approach with isfinite() doesn't work either:

# \pset null '<n>'
Null display is "<n>".

# select
    isfinite(upper('["2019-01-01",]'::daterange)) as upper_null,
    isfinite(upper('["2019-01-01","2019-01-02"]'::daterange)) as
upper_valid,
    isfinite(upper('["2019-01-01",infinity]'::daterange)) as
upper_infinity;
 upper_null │ upper_valid │ upper_infinity
────────────┼─────────────┼────────────────
 <n>        │ t           │ f

… because obviously, upper('["2019-01-01",]'::daterange)) return null. But
at least the second and third cases behave differently. And the first case
does return null, which seems more intuitive.

Reading 8.17.4. Infinite (Unbounded) Ranges, I understand that infinite
cannot be part of the range per se, nevertheless, I think it would make more
sense for it to return true in this scenario.

Identical behaviour observed with:
PostgreSQL 9.5.6 on x86_64-pc-linux-gnu, compiled by gcc (Debian 4.9.2-10)
4.9.2, 64-bit
PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18)
6.3.0 20170516, 64-bit
PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.1.1
20170630, 64-bit
PostgreSQL 10.3 on x86_64-apple-darwin16.7.0, compiled by Apple LLVM version
9.0.0 (clang-900.0.39.2), 64-bit

Thoughts?

PG Bug reporting form <noreply@postgresql.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