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
