Tino,
I am talking about corporate apps, there would never be thousands of
emails in the email servers inbound queue from just a few database
applications. (anyway a thousand emails in a Postfix queue is nothing)
Sometimes it is best to send the email right from the client app, but in
many situations sending a email from the client application may be
blocked by corporate firewall restrictions etc, so sending the email
from the server via a trigger or function is the best bet.
The email should be the last thing that is called, and in postgresql 8.1
you can use error handling in your function if you so desire to avoid
sending a bogus email if there is a problem.
And you can code a trigger that fires when there is a difference of 60
days between dates(I have apps that do so...,and the trigger sends a email)
You have your opinion and I have mine, but mine is backed by real
applications running in a corporate environment, and the situations you
describe NEVER occur, so if some one want's to send a email from
Postgresql I don't think they should be turned back by FUD.
> And you are sure you can handle a few hundred thousands emails in your
> incoming due to a non context aware process which is sending mail?
> There is no such thing like a 60 day trigger either ;)
> In short its usual better to connect with an application to the
> database and handle all that asynchronously - with all the error
> handling and sanetizing. You can send mail from server but you
> really should not :-)
> (Another hint regarding mail: if you send mail to an event and
> then the transaction rolls back - how to you hold back the email?
> And if sending/connection to the mta fails, do you want your
> transaction roll back?)
