Re: range_adjacent and discrete ranges

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: range_adjacent and discrete ranges
Date: 2011-11-20 00:41:31
Message-ID: 1C8C080C-6D8D-4FD5-942C-3D6D2E049BEC@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov19, 2011, at 22:03 , Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-11-20 00:59:08 Re: Singleton range constructors versus functional coercion notation
Previous Message Boszormenyi Zoltan 2011-11-19 21:56:03 Re: SQLDA fix for ECPG