Re: Trigger based logging alternative to table_log

> From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
> To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)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