> From: Jeff Janes <jeff.janes@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
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?
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
usersare 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
finewith 9.6. In general the whole thing would benefit an overhaul, but I think the effort of moving to a better
formatwould 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
forkwith the intention of switching away to a json format eventually.
Glyn