Sim Zacks wrote:
If the database supported background triggers, it might be implemented
by a daemon or by the Listen/Notify framework, but I really couldn't
care less. It is part of the database.
>
Assume the backend would handle this, what would the transaction semantics look like? You
can't wait for the background work to complete before you commit your transaction, so what
should happen when the background "trigger" fails? Or what if a number of such triggers
where fired and then rolled back?
The only thing the database *can* do, is what it does today. It provides the hooks needed
for specialized code that can react on the *outcome* of transactions (and then perform its
task asynchronously using transactions that are autonomous to the first one).
What you're trying to do doesn't belong in triggers and the concept of "background triggers"
doesn't make any sense. Triggers execute (and complete) within a transaction and the work
they perform should be rolled back if the transaction is rolled back.
Kind regards,
Thomas Hallgren
