Re: pre-commit triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pre-commit triggers
Date: 2013-11-26 18:04:30
Message-ID: 10386.1385489070@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> "Write a hack" is not normally advice I like to give or receive.

> We're after a feature that at least one other RDBMS that we know of suports.

> But leaving that aside, what are the restrictions, if any, in what can
> be done in such a callback? Are we allowed to alter the database? If so,
> what happens to FK constraints? Can we raise an ERROR exception?

An XACT_EVENT_PRE_COMMIT action is fairly unconstrained, though if you're
planning to do something that might break FKs, you should do
AfterTriggerFireDeferred() afterwards. Actually it might be smart to
repeat the whole loop that's just before
"CallXactCallbacks(XACT_EVENT_PRE_COMMIT);" in CommitTransaction.

Of course, there's a certain chicken and egg question here. If you're
planning to modify the database in a way that would cause FK triggers to
fire, then this is not exactly the last thing that happens before commit,
is it? So I think this sounds more like fuzzy thinking than a valid
requirement.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-11-26 18:17:23 Re: pre-commit triggers
Previous Message Gurjeet Singh 2013-11-26 17:55:37 Re: Cleaner build output when not much has changed