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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster