PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

PL/Perl sendet E-Mails in Postgresql

Nur weil du es kannst, heißt das nicht, dass du es solltest. Es gibt bessere Möglichkeiten, dies zu tun. Tun Sie es nicht direkt von einem PL. Wenn Sie meine Warnungen ignorieren möchten, verwenden Sie PL/PerlU und schreiben Sie es wie jeden anderen E-Mail-Client. Sie können beliebige CPAN-Module verwenden, die Ihnen das Leben erleichtern.

Zwei Gründe dagegen:

1) Was ist, wenn Ihre Transaktion abgebrochen/zurückgesetzt wird? Sie haben die E-Mail gesendet, aber keine entsprechende Änderung an der Datenbank vorgenommen. Sie tun nicht-transaktionale Dinge innerhalb einer Transaktion.

2) Was ist, wenn Ihre E-Mail auf eine Antwort wartet, bis Sie nach 2 Minuten ein TCP-Timeout erhalten? Werden Sie die E-Mail an den Kunden vergessen? Transaktion abbrechen (kann keine E-Mail senden, kann nicht sagen, dass wir das Teil versendet haben!)?

Das ist ein schlechtes Idee. Tu es nicht. Bedanken Sie sich bei PostgreSQL für diesen Fehler und verschieben Sie ihn in einen anderen Daemon.

Ein viel besser Der Ansatz besteht darin, LISTEN und NOTIFY sowie Warteschlangentabellen zu verwenden. Sie können dann eine Tabelle wie diese erstellen:

CREATE TABLE email_queue (
    id serial not null unique,
    email_from text,
    email_to text not null,
    body text not null
); 

CREATE FUNCTION email_queue_trigger() RETURNS TRIGGER 
LANGUAGE PLPGSQL AS $F$
    BEGIN
        NOTIFY emails_waiting;
    END;
$F$;

Lassen Sie dann Ihre gespeicherte Prozedur in diese Tabelle einfügen.

Dann haben Sie eine zweite Client-App, die auf die E-Mails_waiting hört (sql-Anweisung LISTEN emails_waiting ) und geht dann wie folgt vor:

  1. Überprüft, ob Datensätze in der email_queue vorhanden sind. Wenn nicht, gehen Sie zu 3.
  2. liest Daten, sendet E-Mails, löscht den Datensatz und schreibt fest.
  3. Wenn die Warteschlange leer ist, schläft für x Sekunden
  4. Überprüft beim Aufwecken auf Asynchronität. Benachrichtigungen (hängt von Client-Bibliotheken ab, siehe Dokumente). Wenn ja, gehen Sie zu 1, wenn nicht, gehen Sie zu 3.

Dadurch können Ihre E-Mails zum Senden Ihrer Transaktion in die Warteschlange gestellt und automatisch an eine andere Anwendung weitergeleitet werden, die sich dann mit dem MTA verbinden kann, wenn Sie dies wünschen.

Diese zweite Client-App kann in der Sprache Ihrer Wahl geschrieben werden, wobei alle Tools verwendet werden, die Sie kennen. Es hat den Vorteil, dass der gesamte Netzwerkkram aus der Transaktion heraus ausgeführt wird. Wenn Sie also über einen zweiten SMTP-Server senden und die Verbindung hängt, wartet Ihre gesamte Datenbanktransaktion nicht 2 Minuten auf das Timeout und bricht die Transaktion ab . Es ist damit auch sicherer gegenüber zukünftigen Änderungen der Anforderungen.