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