Rafal Pietrak wrote:
> On Thu, 2006-05-25 at 10:33 +0200, Thomas Hallgren wrote:
>> Rafal Pietrak wrote:
>>> I'd like to propose a 'syntax/semantics' of such trigger:
>>>
>>> Triggers normally execute inside of a transaction.
>>>
>>> A COMMIT within a trigger could mean: "do a fork: fork-1) return to the
>>> main and schedule COMMIT there, fork-2) continue in bacground".
>>>
>> And what if fork-1) returns to the main, attempts the COMMIT but instead and rolls back due
>> to a violated constraint? Where does that leave fork-2?
>>
>> Regards,
>> Thomas Hallgren
>
> No problem at all (at least in particular case of an application I have
> in mind :). The precedure that remains within fork-2 just does a time
> consuming housekeeping. Like a cleanup - always succeeds, even if
> sometimes is not really necesary (like in case of main rolling-back).
>
A somewhat limited use-case to form generic database functionality on, wouldn't you say?
> And that's exacly why I thing that it should be 'released to run' by
> RDBMS *after* the main COMMITS (or ROLLES-BACK). It should be run on
> COMMITED (visible to the world) changes, not on session trancients.
>
Right, so it's not a trigger. It's another session (another transaction) that reacts on a
notification that is sent only if the first transaction succeeds. This is exactly what
notify/listen is for.
Regards,
Thomas Hallgren