Re: pre-commit triggers
От | Andrew Dunstan |
---|---|
Тема | Re: pre-commit triggers |
Дата | |
Msg-id | 5294ED7D.8010001@dunslane.net обсуждение исходный текст |
Ответ на | Re: pre-commit triggers (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 11/26/2013 01:04 PM, Tom Lane wrote: > Andrew Dunstan <andrew@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
В списке pgsql-hackers по дате отправления: