Re: temporal support patch

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

In response to

Browse pgsql-hackers by date

  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