Comments on: PostgreSQL WEST and Temporal Databases

By: Edward Green

Edward Green — Mon, 27 Sep 2010 12:14:39 +0000

if you are interested i came across some articles on how to use periods and scheduling by http://www.sharedshares.com SE. hope you’ll find this information as interesting as I did.

By: Scott Bailey

Scott Bailey — Tue, 13 Oct 2009 17:24:13 +0000

Rob,

Actually you can solve this problem w/o any procedural code. You use the combination of a schedule table and a calendar table to project those into periods in a view. From there its easy to test for overlap or containment.

I’m planning on writing a couple articles on how to use periods and scheduling so I’ll be sure to cover this.

Scott

By: Jeff Davis

Jeff Davis — Tue, 13 Oct 2009 17:15:02 +0000

Yeah, that’s a tough one, I’m glad you brought that up. There are a few tricks, like using generate_series, that can make it almost bearable without resorting to procedural code.

I’ll spend some more time thinking about this one and I’ll see what other people have to say. I think that a reasonable solution exists if we make a significantly more complex type that represents am infinite set of non-contiguous periods. That would be a significant amount of work, and we’d need to make the internal representation flexible enough to represent many patterns.

By: Rob W

Rob W — Tue, 13 Oct 2009 13:08:32 +0000

One of the reasons I like PostgreSQL so much is that it handles dates and time better than most other databases. Although a PERIOD data type is useful for representing *definite* start and end times, another related problem is representing *indefinite* start and end times. One use case (that I had experienced myself) is having to represent employee work-shifts, such as an *indefinite* Monday from 7:00am to 5:00pm (e.g. *any* Monday), and having to ask: does ’2009/10/05 12:00′ as a *definite* instant of time fall within that *indefinite* span of time? It’s a fairly common problem to ask, within which work-shift did this even occur? Unfortunately, PostgreSQL (or any other DBMS I tried) couldn’t help unless I converted the indefinite time to definite timestamps, so I used pgsql functions for this. The logic gets pretty hairy as you hit midnight, cross into the next year, have a work-shift that crosses multiple days, etc.

By: Thom Brown

Thom Brown — Tue, 13 Oct 2009 11:16:49 +0000

That sounds like a very useful development, and I can already see the reduction in clumsy and slow code for date-checking and event clashes. I can only make it to PGDay in Paris unfortunately, but I’ll be following news on this where I can.

It sounds like the alterations for your operator exclusion contraints could pave the way for more useful indexable features like this.

Nice work Jeff!