Re: temporal support patch

>
>
> * I'd very much like to see you make use of Range Types from 9.2; in
> particular, TSTZRANGE would be much better than holding two timestamps.
> If a standard requires you to display two timestamps in certain
> situations, perhaps you could use ranges internally and display the
> boundaries as timestamps when needed.
>

I agree, new range types will be ideal for this

>
> * There is other useful information that could be recorded, such as the
> user who inserted/updated/deleted the record.
>

Yes I considered addition of user ID and transaction ID columns, because it
can be useful in some cases (for example to find all changes made by
transaction). However it wasn't necessary, so i omitted it. It can be
easily added.

>
> * For some purposes, it's very useful to keep track of the columns that
> changed. For instance, a query like "show me any time a salary was
> changed over the last month" (or some other rare event) would be very
> slow to run if there was not some explicit annotation on the historical
> records (e.g. a "columns changed" bitmap or something).
>

Another useful feature. I can take a look on it

> * As Jim mentioned, it might make sense to use something resembling
> inheritance so that selecting from the historical table includes the
> current data (but with no upper bound for the range).
>

See reply to Jim's post.

>
> * It might make sense to hammer out as many of the details as we can
> with an extension. For instance, exactly what options will be available,
> what data types will be used, what objects will be created, the trigger
> code, etc. Then, it will be more obvious exactly what we need to add
> extra core support for (e.g. if we are going to use some inheritance
> like mechanism), and what we need to add syntax sugar for.

> I recommend that you start posting more detailed designs on
> http://wiki.postgresql.org

In which section of wiki can I post detailed design of my solution?

> If you already have code, feel free to submit it for the next commitfest
> ( http://commitfest.postgresql.org ), but this is a relatively large
> project, so it will most likely take several commitfest cycles.
>

I have working patch for postgresql version 9.0.4, but it needs refactoring
before i can submit it, because some parts don't
meet formatting requirements yet. And yes, changes are large, so it will be
better to discuss design first and then deal with code. Do you insist on
compatibility with standard SQL 2011 as Pavel wrote?