PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

PL/Perl envoyer du courrier dans Postgresql

Ce n'est pas parce que vous pouvez que vous devez. Il existe de meilleures façons de le faire. Ne le faites pas directement à partir d'un PL. Si vous voulez ignorer mes avertissements, utilisez PL/PerlU et écrivez-le comme vous le feriez avec n'importe quel autre client de messagerie. Vous pouvez utiliser tous les modules CPAN que vous aimez et qui vous facilitent la vie.

Deux raisons de ne pas :

1) Que se passe-t-il si votre transaction est abandonnée/annulée ? Vous avez envoyé l'e-mail mais n'avez apporté aucune modification correspondante à la base de données. Vous faites des choses non transactionnelles dans une transaction.

2) Que se passe-t-il si votre e-mail se bloque en attendant une réponse jusqu'à ce que vous obteniez un délai d'attente tcp après 2 minutes ? Allez-vous oublier d'envoyer un e-mail au client ? Abandonner la transaction (impossible d'envoyer un e-mail, nous ne pouvons pas dire que nous avons expédié la pièce !) ?

C'est un mauvais idée. Ne le faites pas. Remerciez PostgreSQL pour cette erreur et déplacez-le dans un autre démon.

Un beaucoup mieux L'approche consiste à utiliser LISTEN et NOTIFY, et les tables de file d'attente. Vous pouvez ensuite créer un tableau comme celui-ci :

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

Faites ensuite insérer votre procédure stockée dans cette table.

Ensuite, ayez une deuxième application client qui LISTEN sur les emails_waiting écoute (instruction sql LISTEN emails_waiting ) puis procède comme suit :

  1. Vérifie s'il y a des enregistrements dans email_queue. Si ce n'est pas le cas, passez à 3.
  2. lit les données, envoie un e-mail, supprime l'enregistrement et valide.
  3. Lorsque la file d'attente est vide, dort pendant x secondes
  4. Au réveil, vérifie l'asynchronisme. notifications (dépend des bibliothèques clientes, consultez la documentation). S'il y en a, passez à 1, sinon, passez à 3.

Cela permet à vos e-mails d'être mis en file d'attente pour l'envoi de votre transaction et pour que celle-ci soit automatiquement transmise à une autre application qui peut ensuite se connecter au MTA si vous le souhaitez.

Cette deuxième application client peut être écrite dans la langue de votre choix, en utilisant les outils que vous connaissez. Il a l'avantage de faire toutes les choses réseau hors de la transaction, donc si vous envoyez via un deuxième serveur SMTP et que la connexion se bloque, toute votre transaction de base de données n'attend pas 2 minutes pour qu'elle expire et interrompe la transaction . Il est également plus sûr contre les changements futurs des exigences.