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
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 |