Вижте отличната статия на depesz и pg-message-queue.
Изпращането на имейл директно от базата данни може да не е добра идея. Ами ако DNS разделителната способност е бавна и всичко виси за 30 секунди, след което изтече? Ами ако вашият пощенски сървър се колебае и отнема 5 минути за приемане на съобщения? Ще получавате закачени сесии на база данни в тригера, докато не сте в max_connections и изведнъж не можете да направите нищо, освен да изчакате или да започнете ръчно да анулирате транзакции.
Това, което бих препоръчал, е вашият тригер NOTIFY a LISTEN въвеждане на помощен скрипт, който остава постоянно работещ и свързан с DB (но не в транзакция).
Всичко, което вашият тригер трябва да направи, е INSERT ред в таблица на опашката и изпратете NOTIFY . Вашият скрипт получава NOTIFY съобщение, защото се е регистрирало в LISTEN за него, проучва таблицата на опашката и прави останалото.
Можете да напишете помощната програма на всеки език, който ви е удобен; Обикновено използвам Python с psycopg2 .
Този скрипт може да изпрати имейла въз основа на информацията, която намира в базата данни. Не е нужно да правите цялото грозно форматиране на текст в PL/PgSQL, вместо това можете да замените нещата в шаблон на по-мощен скриптов език и просто да извлечете променливите данни от базата данни, когато NOTIFY влиза.
С този подход вашият помощник може да изпрати всяко съобщение и едва след това да премахне информацията от таблицата на опашката. По този начин, ако има преходни проблеми с вашата пощенска система, които причиняват неуспешно изпращане, не сте загубили информацията и можете да продължите да се опитвате да я изпратите, докато не успеете.
Ако наистина трябва да направите това в базата данни, вижте PgMail.
