Tom Lane wrote:
> The real issue here is transactional semantics. What happens if the
> transaction that fired the trigger rolls back due to a later error?
> The transaction effectively never happened, but you can't unsend the mail.
>
As I browsed to the code for commit, I found this in xact.c (much to my
surprise, I was told nothing like this existed):
/*
* Register or deregister callback functions for end-of-xact cleanup
*
* These functions are intended for use by dynamically loaded modules.
* For built-in modules we generally just hardwire the appropriate calls
* (mainly because it's easier to control the order that way, where
* needed).
*
* Note that the callback occurs post-commit or post-abort, so the
* callback functions can only do noncritical cleanup.
*/
void
RegisterEOXactCallback(EOXactCallback callback, void *arg)
{
...
If Plperlu have hooks for these callbacks, you could prepare the email
using a trigger up to a point where everything is as ready as it
possibly can be without actually being sent. Then, at the end of the
transaction, you either send or remove all prepared emails depending on
the outcome.
I plan to add hooks for EOXactCallbacks in Pl/Java if I no one advice me
that it would be really bad idea.
I would like to make it possible to add a callback that's called just at
the start of a transaction as well. Such callbacks would have the
ability to generate an error and abort the transaction. Would such a
patch be well received?
Kind regards,
Thomas Hallgren
