Scott Bailey wrote: > I would like to add a temporal contrib module. The most important piece > would be adding a period data type and some support functions. Jeff > Davis and I both have temporal projects on pgFoundry, and we've been > collaborating for a while.
I presume you're going to need some backend support and possibly new syntax for some of the operations, right? That seems more urgent to discuss than the possible inclusion into contrib. I'm very pleased to see people working on temporal issues, BTW! I used to work on a database that did a lot of temporal operations, but the DBMS didn't have any temporal data types or operations so we had to use a lot of triggers etc. to achieve that, and it didn't perform well. > Nulls - A common use case for periods is for modeling valid time. Often > the end point is not known. For instance, you know when an employee has > been hired but the termination time typically wouldn't be known ahead of > time. We can either represent these with a null end time or with > infinity. But I'm not sure how to deal with them. Obviously we can test > for containment and overlap. But what about length or set operations? Hmm. Infinity feels like a better match. The behavior of length and set operations falls out of that naturally. For example, length of a period with an infinite beginning or end is infinite. For set operations, for example the intersection of [123, infinity] and [100, 160] would be [123, 160]. > Non-contiguous Sets - A period defines a contiguous set of time. But > many times we need to work with non-contiguous sets (work shifts in a > week, bus schedules, etc). Right now, I'm using period arrays. But > period arrays can contain overlapping and adjacent periods. And we have > no way to indicate that a period array has been coalesced into a > non-contiguous set. And what indexing strategies could be used with > non-contiguous sets? I'd stick to your current definition that a period is a contiguous set of time. A non-contiguous set consists of multiple contiguous periods, so it can be represented as multiple rows in a table. > Temporal Keys - We need two types of temporal keys. A primary key, > exclusion type prevents overlap so someone isn't at two places at the > same time. And a foreign key, inclusion type so we can check that the > valid time of a child is contained with in the valid time of the parent. > Jeff is working on the former, but there is no easy way to do the latter. I'm very excited about this. Foreign keys don't seem that hard, you'll need foreign key triggers like we have today, but check for "within" instead of "equal". > Temporal Data and the Relational Model - Date et al > http://books.google.com/books?isbn=1558608559 +1 for the approach in this book. I'm not familiar enough with the TSQL2 spec to say whether it follows it. It should also be kept in mind that although this class of problems are generally thought of as temporal issues, IOW dealing with time, the same approach works with ranges of integers or any other datatype with a well-defined sort order. It would be nice if the temporal data type would allow that too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
