Siehe den wie gewohnt ausgezeichneten depesz-Artikel und pg-message-queue.
Das Versenden von E-Mails direkt aus der Datenbank ist möglicherweise keine gute Idee. Was ist, wenn die DNS-Auflösung langsam ist und alles 30 Sekunden lang hängt und dann abläuft? Was ist, wenn Ihr Mailserver wackelt und 5 Minuten benötigt Nachrichten annehmen? Sie werden Datenbanksitzungen in Ihrem Trigger aufhängen, bis Sie bei max_connections sind und plötzlich können Sie nichts anderes tun, als zu warten oder Transaktionen manuell zu stornieren.
Was ich empfehlen würde, ist, Ihren Trigger NOTIFY zu haben a LISTEN ing-Hilfsskript, das permanent ausgeführt und mit der DB verbunden bleibt (jedoch nicht in einer Transaktion).
Alles, was Ihr Trigger tun muss, ist INSERT eine Zeile in eine Warteschlangentabelle und senden Sie ein NOTIFY . Ihr Skript bekommt den NOTIFY Nachricht, weil sie sich bei LISTEN registriert hat überprüft dafür die Warteschlangentabelle und erledigt den Rest.
Sie können das Hilfsprogramm in jeder beliebigen Sprache schreiben; Normalerweise verwende ich Python mit psycopg2 .
Dieses Skript kann die E-Mail basierend auf Informationen senden, die es in der Datenbank findet. Sie müssen nicht die ganze hässliche Textformatierung in PL/PgSQL vornehmen, Sie können Dinge stattdessen in einer Vorlage in einer leistungsfähigeren Skriptsprache ersetzen und einfach die variablen Daten aus der Datenbank abrufen, wenn ein NOTIFY kommt rein.
Mit diesem Ansatz kann Ihr Helfer jede Nachricht senden und erst dann die Informationen aus der Warteschlangentabelle entfernen. Auf diese Weise haben Sie bei vorübergehenden Problemen mit Ihrem E-Mail-System, die dazu führen, dass das Senden fehlschlägt, die Informationen nicht verloren und können weiterhin versuchen, sie zu senden, bis Sie erfolgreich sind.
Wenn Sie dies wirklich in der Datenbank tun müssen, siehe PgMail.
