On Fri, Feb 11, 2011 at 11:55 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote:
>> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
>> > Updated patch.
>> >
>>
>> The operators << >> and -|- have the following behavior with empty ranges:
>>
>> testdb=# select '-'::int4range << range(200,300);
>> ERROR: empty range
>> testdb=# select '-'::int4range >> range(200,300);
>> ERROR: empty range
>> testdb=# select '-'::int4range -|- range(200,300);
>> ERROR: empty range
>>
>> I'm not sure if that is deliberate behavior, but they seem
>> almost bugs to me.
>
> It's deliberate, but it looks like the error messages could use some
> improvement.
>
>> Wouldn't it be better (and more practical) if these would
>> return false (or perhaps NULL, for 'unknown') ?
>
> I'm hesitant to return NULL when the inputs are known.
>
> If we were to define these functions for empty ranges, I would think
> they would all return true.
>
> "<<" and ">>" ("strictly left of" and "strictly right of", respectively)
> could be seen to start out as true and return false if it finds a point
> overlapping or on the other side.
>
> The primary use case for "-|-" (adjacent) is to see if your ranges are
> contiguous and non-overlapping. For empty ranges, that seems to be true.
>
> I'm not disagreeing with your interpretation really. I think that
> different people will assume different behavior, and so it's more likely
> to cause confusion. An error early on will allow them to do something
> like:
> CASE WHEN myrange? THEN myrange -|- range(10,20) ELSE TRUE END
> So that they (and anyone who reads their query) can see explicitly
> what's happening, without looking in the manual for details.
>
> I'm open to suggestion, however. If we can get a reasonable consensus on
> the values these functions should return, I'll change it.
For what it's worth, my completely uninformed opinion is that
comparison operators shouldn't error out. I haven't read the patch so
I'm not sure what those operators are defined to do, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
