From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Trigger based logging alternative to table_log |
Date: | 2017-03-27 21:19:37 |
Message-ID: | obbvl3$s24$1@blaine.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Janes schrieb am 27.03.2017 um 19:07:
> 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?
Logical replication maybe?
I don't know which programming language you are using, but the JDBC driver has a nice example:
https://jdbc.postgresql.org/documentation/head/replication.html
The upside to a trigger based solution is, that it's faster.
The downside is, that the replication "consumer" has to be running to ensure the logging
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Litt | 2017-03-27 21:23:43 | Re: browser interface to forums please? |
Previous Message | Felix Kunde | 2017-03-27 20:48:09 | Re: Trigger based logging alternative to table_log |