Periods

SQL:2011 introduced the concept of a "period". It takes two existing columns and basically does the same thing as our range types except there is no new storage. I believe if Jeff Davis had given us range types a few years later than he did, it would have been using periods.

Attached is a WIP patch that I have been working on. The only thing left is completing periods on inherited tables, and finishing up pg_dump. I'm posting this now just to make sure my basic foundation is sound, and to let people know that I'm working on this.

The patch itself doesn't have any functionality, it just allows periods to be defined. With that, there are several things that we can do: SYSTEM_TIME periods, which are explicitly not allowed by this patch, will allow us to do SQL standard versioned tables, and also allows some time travel functionality. Application periods can be used in PRIMARY/UNIQUE keys, foreign keys, and give nice new features to UPDATE and DELETE. They also allow "period predicates" which are the same kind of operations we already have for range types. All of that is for future patches that build on the infrastructure presented in this patch.

The SQL standard restricts period columns to dates or timestamps, but I'm allowing anything that has a btree operator class, as is the PostgreSQL way. System periods, once allowed, will only be timestamptz though. Unfortunately, I had to fully reserve the word PERIOD for this.

I'm looking for comments on everything except the pg_dump stuff, keeping in mind that inheritance is not finished either.

Thanks!

This is patch is based off of 71b349aef4.