Re: temporal support patch

Hi,

yes you are right, storing old versions of entry to history table can be
handled with triggers and my solution also uses triggers to do that.
Advantage of my implementation is that user doesn't need to create all
necessary objects (triggers, history table, begin/end columns ...)
manually. He just need to use AS TRANSACTIONTIME clause in CREATE TABLE
command and everything else is done automatically by backend.

I focused on backward compatibility with existing applications, so that if
versioning is added to original table, application can run correctly
without any changes. For example columns for beginning and end timestamp
are added to original table. This requires modifying of star symbol '*'
expansion in SELECT statement processing, because newly added (internal)
column have to be implicitly hidden. The same for INSERT command without
column list.

Simply said, my implementation makes work with temporal tables easier a
minimizes limitations for existing applications. User can work with
temporal table, just like with any other table and don't need to bother
with triggers, columns, history tables etc. For example if you want add
column to table with versioning, you can use simple ALTER TABLE ADD COLLUMN
and column is automatically added to history table too.

Regards
Miroslav Simulcik

2012/5/18 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>

> Miroslav Šimulcík wrote:
> > as a part of my master's thesis I have created temporal support patch
> for PostgreSQL. It enables the
> > creation of special temporal tables with entries versioning. Modifying
> operations (UPDATE, DELETE,
> > TRUNCATE) on these tables don't cause permanent changes to entries, but
> create new versions of them.
> > Thus user can easily get to the past states of the table.
>
> Most of that is something you could handle with triggers (not TRUNCATE of
> course).
>
> What does your proposed feature do that a set of triggers wouldn't?
>
> Yours,
> Laurenz Albe
>