Re: Range Types - typo + NULL string constructor

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>, "Jeff Davis" <pgsql@j-davis.com>
Cc: <pgsql-hackers@postgresql.org>,"Erik Rijkers" <er@xs4all.nl>
Date: 2011-09-19T16:00:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Replace the "New Linear" GiST split algorithm for boxes and points with a

Robert Haas <robertmhaas@gmail.com> wrote:
> Jeff Davis <pgsql@j-davis.com> wrote:
>>> select '[ 2 , NULL )'::int4range;
>>> ERROR:  NULL range boundaries are not supported
>>> LINE 1: select '[ 2 , NULL )'::int4range;
>>
>> I think this might require more opinions. There is a trade-off
>> here between convenience and confusion: accepting NULL is
>> convenient in the constructors, because it avoids the need to
>> have extra constructors just for unbounded ranges; but could lead
>> to confusion between NULL and INF (which are not the same).
> 
> I agree with this line of reasoning.  I think we will be making
> pain for ourselves if we need to invent a bunch more constructors
> just to have a way of indicating an unbounded range, but OTOH I
> don't see any compelling reason why the type input function needs
> to accept N-U-L-L.
 
FWIW, the existing semantics of NULL include not only "UNKNOWN" but
also "NOT APPLICABLE".  It seems fairly natural to think of a range
as being unbounded if the boundary limit is "not applicable".
 
On a practical level, our shop is already effectively doing this. 
We have several tables where part of the primary key is "effective
date" and there is a null capable "expiration date" -- with a NULL
meaning that no expiration date has been set.  It would be nice to
be able to have a "generated column" function which used these two
dates to build a range for exclusion constraints and such.
 
-Kevin