Skip site navigation (1) Skip section navigation (2)

Re: sending mail from Postgres

From: Tony Caduto <tony(dot)caduto(at)amsoftwaredesign(dot)com>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: sending mail from Postgres
Date: 2006-01-01 21:52:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Tino Wildenhain wrote:

> We do not talk about exceptions here. I'm talking about transactions.
> And you never know who will be aborting a transaction after your
> call to the function. No need for referral to the fine manuals :-)

Common Tino, you let users abort transactions? Who else is going to be 
aborting transactions besides you the programmer?
I would never allow that as they would mess everything up.

I only abort transactions in my end user apps when the server throws a 
error, I then evaluate that error and take appropriate action.
That's why having exceptions in your function would work. You are 
inviting trouble letting users control when a transaction ends or starts 
for that matter, they have a tendency to leave them in a non commited 
state for long periods of time.

Transactions need to be short and sweet.

Sure a very long latency email might slow up a transaction for a second 
or two, but like I said for a internal use corporate app, you will never 
even see one second to send a email.

It all depends on your app what will work best.

There is nothing wrong with sending a email directly from a trigger or 
function.  If you really need to scale there are better ways, but for 99 
  percent of apps the way I suggested will work fine and dandy.

I myself, for a high volume email notifictation system would probably 
use some form of a queue, but that would be severe overkill for the 
majority of apps, if it's not broke don't fix it.

I guess we will have to agree to disagree :-)



In response to


pgsql-general by date

Next:From: Tony CadutoDate: 2006-01-02 00:39:09
Subject: using PG with Syslog
Previous:From: Tom LaneDate: 2006-01-01 21:44:01

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group