Re: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values
От | Tom Lane |
---|---|
Тема | Re: BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values |
Дата | |
Msg-id | 27557.1551988399@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15675: upper_inf() always returns false for non-null daterange, tstzrange values (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: