Subject: Re: Fwd: Start up question about triggers
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: "Forums @ Existanze" <forums@existanze.com>
Cc: pgsql-sql@postgresql.org
In-Reply-To: <200606261359.k5QDxE2p004593@auth-smtp.hol.gr>
References: <200606261359.k5QDxE2p004593@auth-smtp.hol.gr>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1151336286.4215.35.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Mon, 26 Jun 2006 10:38:06 -0500

On Mon, 2006-06-26 at 08:59, Forums @ Existanze wrote:
> Hello again,
> 
> The problem is not tracking WHAT changed, this can be done, as we have
> discussed in this thread, the problem is how to replicate the necessary
> commands that will alter a mirror database to reflect what has been changed,
> sequencially and in the order that it has occurred.
> 
> I you can find my first question (I can repost), you will see that this
> problem has arisen due of lack of proper design. This is a requirement that
> has just come into the picture and we have to find a solution for it.
> 
> My initial question was intended to figure out a way to track these changes
> AND create the necessary INSERT,DELETE and UPDATE statements for each of the
> changes that occurr in the entire database. I wanted to avoid having to
> create an audit table for each of the tables in the database. At the moment
> we are counting 82, this will mean another 82 tables, along with 82 triggers
> and so on. 

I'm having a mad scientist moment.

I bet it would be possible to hack pgpool to do this.  Just have it
shoot all the queries that come in to it at the normal database, AND at
a text file or something like that.

Not sure that's any better than using pgsql logging to do the same
thing, but it certainly doesn't seem like it would be that hard to do.