Hello.
Basically my implementation serve for the same thing as table_log extension - entry versioning. It also uses history table and triggers to store old versions of entries. After quick review of table_log extension, here is comparison with my solution:
tale_log advantages compared to my solution:
- no columns added to the original table
- more control over created objects
advantages of my solution compared to table_log
- built in syntax
- more user friendly - everything is done automatically
- no data redundancy - in my extension current versions of entries are stored only once in original table (in table_log - entries are inserted to both original and log table)
- no speed degradation for INSERT statement - no triggers called on INSERT
- faster triggers - triggers in my implementation are based on referential integrity triggers and use prepared statements
- original table alterations are automatically done also on history table
- easier selection of data valid in specific time - each row contains start and end time
- easier restoration to table - TRANSACTIONTIME AS OF expression SELECT * INTO restoration_table FROM original_table;
Regards
Miroslav Simulcik
2012/5/17 A.M.
<agentm@themactionfaction.com> On May 16, 2012, at 5:14 PM, Miroslav Šimulčík wrote:
> Hi all,
>
> 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.
>
> Basic information on temporal databases can be found on
http://en.wikipedia.org/wiki/Temporal_database >
I currently use the table_log extension: http://pgfoundry.org/projects/tablelog/
Other than the built-in syntax, how does your implementation differ feature-wise?
Cheers,
M
