Re: Implementing a change log

From: Mike Rylander <mrylander(at)gmail(dot)com>
To: Berend Tober <btober(at)seaworthysys(dot)com>, Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Implementing a change log
Date: 2005-09-20 12:00:55
Message-ID: b918cf3d050920050029d8149e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/20/05, Berend Tober <btober(at)seaworthysys(dot)com> wrote:
> /*
> The following is based on suggestion by Mike Rylander posted on
> Postgresql-General
> Sun, 18 Sep 2005 23:29:51 +0000
>
> Rylander's original suggestion employed a trigger and tracked
> only row updates. My implementation makes use of rules and
> handles both updates and deletions.
> */

I'm glad that was inspirational for you. Not to nit pick, but my
trigger based version did in fact track deletions:

CREATE TRIGGER audit_$$ || sch || $$_$$ || tbl || $$_update_trigger
AFTER UPDATE OR DELETE ON $$ || sch || $$.$$ || tbl || $$ FOR EACH ROW
^^^^^^^
EXECUTE PROCEDURE auditor.audit_$$ || sch || $$_$$ || tbl || $$_func ();

You may want to consider using the LIKE style of table copying, as it
strips all constraints from the new table. It's safer IMHO, as this
way you wouldn't have to worry about the primary key being propagated
to the new table (and accidentally forgetting to remove it).

--
Mike Rylander
mrylander(at)gmail(dot)com
GPLS -- PINES Development
Database Developer
http://open-ils.org

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Berend Tober 2005-09-20 13:14:00 Re: Implementing a change log
Previous Message Daniel Schuchardt 2005-09-20 11:15:13 Re: shared Locks