On Nov19, 2011, at 22:03 , Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> On Fri, 2011-11-18 at 14:47 -0500, Tom Lane wrote:
>>> Yeah, probably not. However, I don't like the idea of
>>> '(3,4)'::int4range throwing an error, as it currently does, because it
>>> seems to require the application to have quite a lot of knowledge of the
>>> range semantics to avoid having errors sprung on it.
>
>> OK, then let's make '(3,4)'::int4range the empty range. (3,3) might be
>> OK as well (for any range type), because at least it's consistent.
>
>> The one that I find strange is [3,3), but I think that needs to work for
>> the range_adjacent idea to work. Seeing it as useful in the context of
>> range_adjacent might mean that it's useful elsewhere, too, so now I'm
>> leaning toward supporting [3,3) as an empty range.
>
> OK, so the thought is that the only actual error condition would be
> lower bound value > upper bound value? Otherwise, if the range
> specification represents an empty set, that's fine, we just normalize it
> to 'empty'. Seems consistent to me.
+1. Making the error condition independent from the boundary type makes
it easy for callers to avoid the error conditions. And it should still
catch mistakes that stem from swapping the lower and upper bound.
best regards,
Florian Pflug