Re: Ranges for well-ordered types

Michael,

First off, mark me down as one of the people interested in having this ... 
I've been hacking a lot of the same functionality using data-push functions 
and triggers, and boy howdy, it's messy.

I do think Jim is right, though, in that we may want to look for portions of 
the functionality which are achievable in the context of one PostgreSQL 
version, unless you're going to be working full-time on this patch.   Or 
maybe queue it up for next summer's Summer of Code.  Not sure what that 
portion would be, though.

In real-world calendaring applications, I *certainly* see the need for a 
successor function.  However, that would require being able to define 
timestamps with a variable precision, e.g. TIMESTAMP('5 minutes').  This, by 
itself would be a significant effort, yet useful ... maybe that's where to 
start?

You're probably going to have to give up on B-Tree indexes for PERIODs, and 
look towards GiST.  For one thing, I would see UNIQUE in the context of a 
PERIOD defined as non-overlapping.  e.g.:

Given
UNIQUE (name, period)
Name        Period
Joe            2006-06-11 14:00:00->17:35:00
Marsha        2006-06-11 15:00:00->19:00:00
Ralph        2006-06-11 15:15:00->15:30:00

I would want (in a calendaring application) an attempt to insert:
Joe            2006-06-11 17:00:00->19:00:00
... to fail, as well as any attempt to:
UPDATE periods SET name = 'Marsha' WHERE name = 'Ralph';

... although it's possible that UNIQUE is not really the right name for that 
kind of constraint, although it serves the same purpose.   But I don't think 
in this context that a B-Tree would be capable of fulfilling it.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco