> From: Jeff Janes <jeff.ja...@gmail.com> > To: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org> > Sent: Monday, 27 March 2017, 18:08 > Subject: [GENERAL] Trigger based logging alternative to table_log > > 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 in the 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 in the 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 this from scratch. But I'd rather >preserve the existing log tables than either throw away that data, or port it >over to a new format. > >Is there any better-maintained code out there which would be compatible with >the existing schema used by table_log?
I was in exactly the same situation a few years ago. As you say ideally we'd move away from table_log - but when the users are used to doing things the table_log way and they like it... I have a slightly more up to date fork (here: https://github.com/glynastill/pg_table_audit), which as I recall works fine with 9.6. In general the whole thing would benefit an overhaul, but I think the effort of moving to a better format would be less. I also wrote a pl/pgsql version as mentioned by Felix, but I wasn't ever particularly happy it so stuck with the above fork with the intention of switching away to a json format eventually. Glyn -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
