Why does the range type's upper function behave inconsistently?

Поиск
Список
Период
Сортировка
Искать
От
Dane Foster
Тема
Why does the range type's upper function behave inconsistently?
Дата
Msg-id
CA+WxinKGxfMK7X7dw3Ni4FoVxbEhPNuePTCkEVR-nYX=4rWKjg@mail.gmail.com
Список
Дерево обсуждения
Why does the range type's upper function behave inconsistently? Dane Foster <studdugie@gmail.com>
Re: Why does the range type's upper function behave inconsistently? Tom Lane <tgl@sss.pgh.pa.us>
Re: Why does the range type's upper function behave inconsistently? Julien Rouhaud <julien.rouhaud@dalibo.com>
Re: Why does the range type's upper function behave inconsistently? Adrian Klaver <adrian.klaver@aklaver.com>
Re: Why does the range type's upper function behave inconsistently? Dane Foster <studdugie@gmail.com>
I don't understand the inconsistent behavior of the range types' upper function in regard to inclusive ranges.

For example(s):
1. SELECT upper(int4range(1, 4, '[]')) = 4; -- FALSE
2. SELECT upper(int8range(1, 4, '[]')) = 4; -- FALSE
3. SELECT upper(numrange(1, 4, '[]')) = 4; -- TRUE
4. SELECT upper(tstzrange('2015-07-01: 00:00:00', now(), '[]')) = now(); -- TRUE
5. SELECT upper(daterange('2015-01-01', current_date, '[]')) = current_date; -- FALSE

#1 & #2 are FALSE because upper returns 5 instead of 4; and #5 is FALSE because upper returns: current_date + interval '1 day'. I don't understand the logic behind why it would return the inclusive upper bound value for some ranges and not others. If anyone can shed some light on this behavior it would be greatly appreciated.

One of things I originally tried to use upper for was CHECK constraints. That was until I wrote some unit tests and realized that upper doesn't consistently work the way I expected. Of course my assumptions are probably wrong so that's why I'm asking for clarification.

Regards,

Dane
В списке pgsql-general по дате отправления
От: Greg Sabino Mullane
Дата:
Сообщение: Re: database-level lockdown
От: Julien Rouhaud
Дата:
FAQ