Re: Periods

2018-05-26 22:56 GMT+02:00 Vik Fearing <vik(dot)fearing(at)protonmail(dot)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.
>