Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My original intention was to keep two sets of tables. The first
containing only the working set of current records. The second
containing all prior versions. I haven't experimented with such a setup
yet and I'm
Berend Tober wrote:
...See User Comments at
http://www.postgresql.org/docs/8.0/interactive/tutorial-inheritance.html;
for something that should set you afire.
And, commenting on my own post, try this cool function:
/*
The following is based on suggestion by Mike Rylander posted on
On 9/20/05, Berend Tober [EMAIL PROTECTED] wrote:
/*
The following is based on suggestion by Mike Rylander posted on
Postgresql-General
Sun, 18 Sep 2005 23:29:51 +
Rylander's original suggestion employed a trigger and tracked
only row updates. My implementation makes use of rules and
Mike Rylander wrote:
On 9/20/05, Berend Tober [EMAIL PROTECTED] wrote:
/*
The following is based on suggestion by Mike Rylander posted on
Postgresql-General
Sun, 18 Sep 2005 23:29:51 +
Rylander's original suggestion employed a trigger and tracked
only row updates. My implementation
On Tuesday 20 September 2005 08:44, Berend Tober wrote:
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[MS: on audit tables]
Can anyone relate their experiences with such a thing? Which
approaches should I take into consideration?
I like the multi-table
On 9/20/05, Berend Tober [EMAIL PROTECTED] wrote:
[snip]
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My original intention was to keep two sets of tables. The first
containing only the working set of current records. The second
containing all prior versions. I haven't experimented with such a setup
yet and I'm wondering if it is even
In my current project I have a customer requirement for implementing a
change log. This is not just for auditing purposes, rather it is meant
to be accessible by users so they can get an overview of the change
history of an object. The entire data set is not big, I'm expecting
considerably
On 9/18/05, Michael Schuerig [EMAIL PROTECTED] wrote:
In my current project I have a customer requirement for implementing a
change log. This is not just for auditing purposes, rather it is meant
to be accessible by users so they can get an overview of the change
history of an object. The
On Monday 19 September 2005 01:29, Mike Rylander wrote:
On 9/18/05, Michael Schuerig [EMAIL PROTECTED] wrote:
In my current project I have a customer requirement for
implementing a change log. This is not just for auditing purposes,
rather it is meant to be accessible by users so they can
10 matches
Mail list logo
