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.albe@wien.gv.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
