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. <age...@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 > > > > Hello! > > 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 > > > >
