On Fri, Feb 11, 2011 at 11:55 AM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers