> Typically this is bad idea. Better save the email info on a table and
> fire a NOTIFY. An external daemon would be listening to that
> notification, and send the email from the data in the table, which it
> can subsequently delete or mark as used.
>
> This is also better because you have a chance to retry if your SMTP is
> down or whatever. If you fail to send the mail in a trigger or
> function, you have no way to wait 10 minutes without clogging your
> application.
>
>
I wouldn't go so far as to say it's a bad idea(it really depends on what
you need to do).
I have been using a plperl based solution in a heavily used client
server application.
We don't send the emails via a trigger though, strictly initiated by a
procedure call from the client. Never had one single problem doing it
this way.
You wouldn't clog your application if you initiate the process through a
separate connection to the server which is initiated from a thread.
--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration
