From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: temporal support patch |
Date: | 2012-08-21 05:13:02 |
Message-ID: | 503318DE.5010607@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-08-21 05:22:55 | Re: temporal support patch |
Previous Message | Jeff Davis | 2012-08-21 05:04:06 | Re: temporal support patch |