This is important since in a schedule two appointments will have a gap between them if the intervals are open (2..4),(4..6) implies nothing scheduled at 4 or will overlap if tey are closed [2..4],[4..6] double booking at 4. The correct solution is to use mixed intervals e.g (2..4], (4..6] now the complete interval is covered but there is no overlap.

There are many other cases where this is an issue, in fact it is an issue for any grouped data from a continuous set. If we want temporal keys to be sound we would need a solution that caters for this.

Anyway, I would suggest (or maybe second) the notion of finest granularity by default, and a mechanism (as you propose), to back off on the precision as needed.

PERIOD needs some more docs and test cases as well.

Yes. I’ve been focusing on the core engine changes required, and Scott is working on the data types and their semantics.

first endpoint is inclusive and the second point is exclusive

As a default, that’s fine. But there are cases where you want an inclusive end time, as well.

Also think it would be useful to have a way to specify the granularity of the PERIOD.

Scott had the same idea. I think this can be accomplished with a CHECK constraint, like

CHECK (
  first(during) = date_trunc('hour', first(during)) AND
  next(during) = date_trunc('hour', next(during))
)

but it would be nice to make it a little easier to express.

A period defines a contiguous set of values but we can define it by the end points. The defaults are inclusive start, exclusive end.

I think if you gave from() a little more thought, you’d change your mind.

I agree with you on being able to define the granularity. But my thought is that it would have to be set at the database level rather than say at the column level.

I’d like to generalize the concept so that we’ll be able to define a range of ints, dates, timestamps, numeric, etc.

http://www.postgresqlconference.org/2009/west/talks/temporal_data

It is based on his CHRONOS project:
http://sourceforge.net/projects/chronosdb/

The extensions cover some of the points you raised.

PERIOD needs some more docs and test cases as well.

The docs that are there describe PERIOD as a “set” rather than as two endpoints, which is how all examples are laid out. I think a PERIOD should have two endpoints (+/- infinity included). If you have need for a more fancy datatype it can have a slightly different name. So the next() and prior() functions just look a little overcooked. Better to have just from() and to() or similar.

Think it would be useful to have the default as the first endpoint is inclusive and the second point is exclusive, so they stack together neatly by default.

Also think it would be useful to have a way to specify the granularity of the PERIOD. In many cases a period is expressed only in days, not timestamps. For example in your hotel room example you don’t book a hotel room for an exact second, you book one night at a time. Of course, some hotels do book by the hour, but very few by the second. It wouldn’t be much use for businesses to refuse a booking because there was a 10ms overlap between 2 5 day bookings – nor would anybody really want to record that detail.

So perhaps we need DATEPERIOD (2 DATEs) and TIMEPERIOD (2 TIMESTAMPs). It might be useful to be able to specify this like PERIOD(INTERVAL), so you can book holiday cottages in weeks, scaffolding by month etc.. Whatever the business needs.

The trigger method, as described, doesn’t correctly handle concurrent inserts. That illustrates my main concern which is that there is too much code there and it is likely to have errors – I think you showed that in the number of posts taken as well. Anyhow, it is certainly slower than the in-database approach Jeff has designed.

CREATE OR REPLACE FUNCTION dont_overlap_reservations() RETURNS trigger AS $$
DECLARE
overlaps text;
BEGIN
SELECT whom INTO overlaps
FROM room_reservation
WHERE room = NEW.room
AND beginning <= NEW.until
AND until >= NEW.beginning
LIMIT 1;
IF FOUND THEN
RETURN NULL;
ELSE
RETURN NEW;
END IF;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION dont_overlap_reservations() RETURNS trigger AS $$
DECLARE
overlaps text;
BEGIN
SELECT whom INTO overlaps
FROM room_reservation
WHERE room = NEW.room
AND beginning = NEW.beginning
LIMIT 1;
IF FOUND THEN
RETURN NULL;
ELSE
RETURN NEW;
END IF;
END;
$$ LANGUAGE plpgsql;

Plus, obviously, you would use a timestamp rather than a time,

and it’s probably a good idea to declare (room,beginning,until) as the primary key. For more than five rows an index might be useful.