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?
