Re: Plperlu and sending emails, is it safe?

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Plperlu and sending emails, is it safe?
Date: 2004-06-28 15:18:30
Message-ID: 40E036C6.1040202@mailblocks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Hallgren 2004-06-28 15:32:55 Re: Plperlu and sending emails, is it safe?
Previous Message UMPA Development 2004-06-28 15:15:48 Group by - Case insensitivity