Date: Fri, 8 Apr 2005 10:59:28 -0400
From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-sql@postgresql.org
Subject: Re: Question on triggers and plpgsql
Message-ID: <20050408145928.GA27718@phlogiston.dyndns.org>
References: <4255AA15.8000508@mochima.com>
	<BE1E8DAA-A829-11D9-9125-000A95B03262@pgedit.com>
	<fef7e50cf33b53ca481ecb2554cd6403@mail.nih.gov>
	<14244.1112970986@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14244.1112970986@sss.pgh.pa.us>
User-Agent: Mutt/1.5.6+20040907i

On Fri, Apr 08, 2005 at 10:36:26AM -0400, Tom Lane wrote:

> AFAICS the only way that you could get into a can't-roll-back situation
> is if the trigger tries to propagate the update outside the database.
> For instance, the proverbial trigger to send mail: once sent you can't
> cancel it.  But really this is dangerous even in an AFTER trigger ---
> the transaction could still be rolled back after the AFTER trigger
> fires.

People who know more about this will no doubt correct me, but isn't
such a case crying out for LISTEN/NOTIFY instead?  That is, your
trigger puts the mail content into a table of mails to be sent, and
wakes up the mail-sender client with the NOTIFY; the NOTIFY and the
commit to the mail-it table only happen in that case if the
transaction commits.  And since mail is async anyway, the extra few
seconds shouldn't make any difference, right?

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
The plural of anecdote is not data.
		--Roger Brinner