Why does the range type's upper function behave inconsistently? - Mailing list pgsql-general

From Dane Foster
Subject Why does the range type's upper function behave inconsistently?
Date
Msg-id CA+WxinKGxfMK7X7dw3Ni4FoVxbEhPNuePTCkEVR-nYX=4rWKjg@mail.gmail.com
Whole thread Raw
Responses 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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Why does the range type's upper function behave inconsistently?  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
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 by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: database-level lockdown
Next
From: Julien Rouhaud
Date:
Subject: Re: Why does the range type's upper function behave inconsistently?