Re: Implementing a change log

From: Berend Tober <btober(at)seaworthysys(dot)com>
To: mrylander(at)gmail(dot)com
Cc: Postgresql-General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Implementing a change log
Date: 2005-09-20 13:14:00
Message-ID: 43300B18.2010302@seaworthysys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mike Rylander wrote:

>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 ...
>
>

That was indeed pretty cool.

>...did in fact track deletions:
>
>

Guess I was too excited to actually read the whole thing more closely
once I grasped the direction you were going!!

>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).
>
>
I'm glad you pointed that out because you reminded me that when I tried
the original idea from Greg Patnude in Mar 2005 using inheritance, I did
indeed run into a problem with constraints. The problem there I think
was that I had a check constraint on the table for which I created the
audit log table, but the check constraint was defined in a different
schema than the original table. Something about the way inheritance
table creation works found this a problematic situation. I'll have to
revisit that and see if using LIKE overcomes that problem.

I guess I originally thought using INHERIT rather than LIKE was that,
having the audit history, I might at some point present a select view
across both the base and descendant tables or something ("...if you
record it, they (PHB's) will eventually ask for a report on it..."), but
I haven't actually had an implementation where such an audit history
table was actually required in production -- I'm just exercising the
functionality and exploring the quirks in order to be prepared for when
such a requirement is actually promulgated.

Any other significant distinquishing features of INHERIT verses LIKE for
this kind of use that you (or others) can think of?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Schuerig 2005-09-20 13:23:17 Re: Implementing a change log
Previous Message Mike Rylander 2005-09-20 12:00:55 Re: Implementing a change log