Re: Trigger based logging alternative to table_log

> 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