On 08/21/2012 12:52 PM, Jeff Davis wrote:
On Mon, 2012-08-20 at 16:32 -0700, Josh Berkus wrote:
This is sounding like a completely runaway spec on what should be a
simple feature.
My feeling as well. However, we will eventually want to coalesce around
some best practices and make it easy and robust for "typical" cases.
Personally, I would prefer a tool which just made it simpler to build my
own triggers, and made it automatic for the history table to track
changes in the live table. I think anything we build which controls
what goes into the history table, etc., will only narrow the user base.
FWIW, I've found the ability to exclude columns from my history triggers
to be important because of:
- "optimistic locking" fields used by some clients; and
- Trigger-maintained summary fields
Without being able to apply some exclusions there's just too much churn
in the history of some tables.
Here's what I'm using at the moment:
http://wiki.postgresql.org/wiki/Audit_trigger_91plus
(I know storing both the relation oid and the text-form table and schema
name is redundant. The text is handy if the table is dropped and
recreated, though, and the oid is quicker & easier much of the time).
I use both the per-query and per-row forms depending on the granularity
I need.
--
Craig Ringer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
