> I have some code which uses table_log (http://pgfoundry.org/projects/tablelog/) to keep a log of changes to selected
tables.
> I don't use the restore part, just the logging part.
> It creates a new table for each table being logged, with several additional columns, and adds triggers to insert rows
inthe new table for changes in the original.
> The problem is that table_log hasn't been maintained in nearly 10 years, and pgfoundry itself seems to have one foot
inthe grave and one on a banana peel.
> There are several other systems out there which store the data in hstore or json, which I would probably use if doing
thisfrom scratch. But I'd rather preserve the existing log tables than either throw away that data, or port it over to
anew format.
> Is there any better-maintained code out there which would be compatible with the existing schema used by table_log?
>Cheers,
>Jeff
Afaik, there is no compatible solution. If tablelog works for you then keep it. Do you miss a feature or why do you
worryabout the unmaintained code base? I think, if there would be a problem with any new version that the developer
wouldfix it. There is also an existing github repo (https://github.com/glynastill/table_log_pl).
Recently, I have done a comparison of different audit tools to check how good my creation (pgMemento) works compared to
theothers. So I know how most of them work. tablelog for example logs both OLD and NEW. So you got all your data twice.
Othersolutions log either OLD of NEW. tablelog uses only one timestamp field whereas others using two (or a range).
As tablelog is using history tables with relational layout I would suggest to consider other extensions that do a
similarthing. If you are interested in only logging the data you might check out the temporal_tables extension
(http://pgxn.org/dist/temporal_tables/).In my test it had the least impact to write operations and disk consumption.
Using hstore or json for logging might sound cool in the first place, but it only has its benefits if you don't want to
adaptthe auditing behaviour to schema changes (like new columns etc.). With pgMemento I decided to go for jsonb but
aftermany hours of programming complex restoring functions I can say that my only real argument of using it now, is
thatI only log values of changed fields. I like that but it makes the trigger overhead bigger.
Greetings from Berlin
Felix