From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, damian(at)sepczuk(dot)pl |
Subject: | Re: BUG #12568: upper of int4range unexpected value |
Date: | 2015-01-16 16:41:57 |
Message-ID: | 28344.1421426517@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> damian-2 wrote
>> While technically 3 is an upper bound of the integer range [1,3) = {1,
>> 2}, so are all natural numbers 2. I would expect the 'upper' function to
>> return the supremum (least upper bound) of the range.
>> In my opinion the result of upper('[1,2]'::int4range) = 3 is unexpected.
> This is not a bug because the answer given, while not what you expect, is
> not incorrect if you allow for the fact that the given bound can be either
> inclusive or exclusive when dealing with a discrete range.
> You already pointed out why the exclusive bound answer is chosen - it is a
> natural consequence of the canonical form chosen for the type.
Yeah. upper() is a simple representation-extraction function, so it's
going to give the stored value which is 3.
There might well be use-cases which would justify inventing infimum() and
supremum() functions that behave as described, but we're not going to
change the behavior of upper/lower at this point.
The use-cases would have to be pretty darn convincing though, because
AFAICS there's no way to provide these functions in a generic way: there'd
need to be new per-range-type support functions to implement them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G Johnston | 2015-01-16 16:42:34 | Re: BUG #12556: Clause IN and NOT IN buggy |
Previous Message | Mike Porter | 2015-01-16 16:36:39 | Re: BUG #12560: can not run alot of databases |