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.

DROP TABLE IF EXISTS room_reservation CASCADE;

CREATE TABLE room_reservation (
whom TEXT NOT NULL,
room TEXT NOT NULL,
beginning TIME WITHOUT TIME ZONE NOT NULL,
until TIME WITHOUT TIME ZONE NOT NULL
);

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;

– WARNING
– multiple triggers on a single table are called in alphabetical
– order so lets name our trigger something z-ish
CREATE TRIGGER zzz_no_overlap
BEFORE INSERT OR UPDATE ON room_reservation
FOR EACH ROW
EXECUTE PROCEDURE dont_overlap_reservations();

INSERT INTO room_reservation (whom,room,beginning,until)
VALUES (‘Ashley’, ‘2B’, ‘8:00′, ‘9:00′);
INSERT INTO room_reservation (whom,room,beginning,until)
VALUES (‘Brett’, ‘2B’,'10:00′, ‘13:00′);
INSERT INTO room_reservation (whom,room,beginning,until)
VALUES (‘Chris’, ‘2B’,'14:00′, ‘15:00′);
INSERT INTO room_reservation (whom,room,beginning,until)
VALUES (‘Dale’, ‘2B’,'17:00′, ‘18:00′);
INSERT INTO room_reservation (whom,room,beginning,until)
VALUES (‘Eden’, ‘2B’,'12:00′, ‘16:00′);