2018-05-26 22:56 GMT+02:00 Vik Fearing <vik.fear...@protonmail.com>: > 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! >
looks interesting Regards Pavel > > > This is patch is based off of 71b349aef4. >
