Vedi l'eccellente articolo di depesz e pg-message-queue.
L'invio di e-mail direttamente dal database potrebbe non essere una buona idea. Cosa succede se la risoluzione DNS è lenta e tutto si blocca per 30 secondi, quindi va in timeout? Che cosa succede se il tuo server di posta è traballante e impiega 5 minuti accettare messaggi? Otterrai sessioni di database bloccate nel tuo trigger finché non sarai a max_connections e all'improvviso non puoi far altro che aspettare o iniziare ad annullare manualmente le transazioni.
Quello che consiglierei è avere il tuo trigger NOTIFY un LISTEN ing script di supporto che rimane permanentemente in esecuzione e connesso al DB (ma non in una transazione).
Tutto ciò che il trigger deve fare è INSERT una riga in una tabella di coda e invia un NOTIFY . Il tuo script riceve il NOTIFY messaggio perché si è registrato a LISTEN per esso, esamina la tabella delle code e fa il resto.
Puoi scrivere il programma di supporto in qualsiasi lingua sia conveniente; Di solito uso Python con psycopg2 .
Quello script può inviare l'e-mail in base alle informazioni che trova nel database. Non devi eseguire tutta la brutta formattazione del testo in PL/PgSQL, puoi invece sostituire le cose in un modello in un linguaggio di scripting più potente e semplicemente recuperare i dati variabili dal database quando un NOTIFY entra.
Con questo approccio il tuo aiutante può inviare ogni messaggio e solo allora rimuovere le informazioni dalla tabella della coda. In questo modo, se si verificano problemi temporanei con il tuo sistema di posta che causano il fallimento dell'invio, non hai perso le informazioni e puoi continuare a tentare di inviarle finché non ci riesci.
Se proprio devi farlo nel database, vedi PgMail.
