Re: temporal support patch

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: David Johnston <polobo(at)yahoo(dot)com>
Cc: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, 'Vlad Arkhipov' <arhipov(at)dc(dot)baikal(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: temporal support patch
Date: 2012-08-21 04:33:45
Message-ID: 1345523625.30161.28.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2012-08-20 at 19:17 -0400, David Johnston wrote:
> Ideally the decision of whether to do so could be a client decision. Not
> storing intra-transaction changes is easier than storing all changes. At
> worse you could stage up all changed then simply fail to store all
> intermediate results within a given relation. It that case you gain nothing
> in execution performance but safe both storage and interpretative resources.
> So the question becomes is it worth doing without the ability to store
> intermediate results? If you were to ponder both which setup would the
> default be? If the default is the harder one (all statements) to implement
> then to avoid upgrade issues the syntax should specify that it is logging
> transactions only.

I think the biggest question here is what guarantees can be offered?
What if the transaction aborts after having written some data, does the
audit log still get updated?

> I see the "user" element as having two components:

I think this is essentially a good idea, although as I said in my other
email, we should be careful how we label the application-supplied
information in the audit log.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-08-21 04:52:51 Re: temporal support patch
Previous Message Jeff Davis 2012-08-21 04:24:29 Re: temporal support patch