On 11/26/2013 01:04 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
