Re: pre-commit triggers

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:50:37
Message-ID: 5294ED7D.8010001@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/26/2013 01:04 PM, Tom Lane wrote:
> 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.

As far as I know the client isn't proposing to alter the database at
all. I'm just trying to get a clear understanding of the limitations of
this approach.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2013-11-26 19:04:14 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Peter Eisentraut 2013-11-26 18:42:16 Re: [PATCH] SQL assertions prototype