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