PL/Perl stuur mail in Postgresql

Alleen omdat je het kunt, wil nog niet zeggen dat je het moet. Er zijn betere manieren om dit te doen. Doe het niet rechtstreeks vanuit een PL. Als je mijn waarschuwingen wilt negeren, gebruik dan PL/PerlU en schrijf het zoals je elke andere e-mailclient zou doen. U kunt elke gewenste CPAN-module gebruiken die uw leven gemakkelijker maakt.

Twee redenen om het niet te doen:

1) Wat als uw transactie wordt afgebroken/teruggedraaid? U hebt de e-mail verzonden, maar heeft geen overeenkomstige wijziging in de db aangebracht. Je doet niet-transactionele dingen binnen een transactie.

2) Wat als uw e-mail blijft hangen in afwachting van een reactie totdat u na 2 minuten een tcp-time-out krijgt? Vergeet je de klant te e-mailen? De transactie afbreken (kan geen e-mail verzenden, kan niet zeggen dat we het onderdeel hebben verzonden!)?

Dit is een slechte idee. Doe het niet. Bedank PostgreSQL voor deze fout en verplaats het naar een andere daemon.

Een veel betere benadering is het gebruik van LISTEN en NOTIFY, en wachtrijtabellen. U kunt dan een tabel als volgt maken:

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$;

Laat dan uw opgeslagen procedure in die tabel invoegen.

Gebruik dan een tweede client-app die LISTENs op de emails_waiting luistert (sql statement LISTEN emails_waiting ) en doet dan als volgt:

1. Controleert of er records in de email_queue staan. Zo niet, ga naar 3.
2. leest gegevens, verzendt e-mail, verwijdert de record en legt vast.
3. Als wachtrij leeg is, slaapt x seconden
4. Controleert bij het ontwaken op async. meldingen (afhankelijk van clientbibliotheken, check docs). Zo ja, ga naar 1, zo niet, ga naar 3.

Hierdoor kunnen uw e-mails in de wachtrij worden geplaatst voor het verzenden van uw transactie en dat deze automatisch wordt doorgegeven aan een andere applicatie die vervolgens verbinding kan maken met de MTA als u dat wilt.

Die tweede client-app kan worden geschreven in de taal van uw keuze, met behulp van alle tools die u kent. Het heeft het voordeel dat alle netwerkdingen uit de transactie worden gehaald, dus als u via een tweede SMTP-server verzendt en de verbinding vastloopt, wacht uw hele databasetransactie niet 2 minuten voordat deze een time-out heeft en de transactie afbreekt . Het is dus ook veiliger tegen toekomstige wijzigingen in vereisten.