Обсуждение: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values
BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values
От
PG Bug reporting form
Дата:
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