Обсуждение: PL/Perl 64-bit and sending emails
Hello! I've been running the 64-bit version of 8.3.4 on OpenSolaris 2009.06 for over a year. Now, I need to put a perl function call into it to allow emails to be sent by the database backend. I tried installing plperl, but it looks like only a 32-bit version is available. Does the 64-bit version of plperl exist? Or, does someone know of another way to get the backend to send an email? Thanks! Mark
On Sep 3, 2009, at 11:30 AM, Mark Lubratt wrote: > Hello! > > I've been running the 64-bit version of 8.3.4 on OpenSolaris 2009.06 > for over a year. Now, I need to put a perl function call into it to > allow emails to be sent by the database backend. I tried installing > plperl, but it looks like only a 32-bit version is available. Does > the 64-bit version of plperl exist? Or, does someone know of > another way to get the backend to send an email? Have a queue table in the database you put your emails into and an external process that polls the table, sends the email and deletes the entry from the queue. Apart from avoiding the ickiness of doing high latency work from a database function this also makes sending email transaction safe - if the transaction rolls back after "sending" the email, the email doesn't get sent. Using listen/notify based on a trigger on the table makes it a little more responsive. This comes up fairly often. It's probably worth doing a tidy perl daemon to handle it and stashing it up on pgfoundry. Cheers, Steve
Hi, Steve Atkins <steve@blighty.com> writes: > On Sep 3, 2009, at 11:30 AM, Mark Lubratt wrote: >> Or, does someone know of another way to get the >> backend to send an email? > > Have a queue table in the database you put your emails into and an external > process that polls the table, sends the email and deletes the entry from > the queue. Apart from avoiding the ickiness of doing high latency work from > a database function this also makes sending email transaction safe - if the > transaction rolls back after "sending" the email, the email doesn't get > sent. > > Using listen/notify based on a trigger on the table makes it a little more > responsive. > > This comes up fairly often. It's probably worth doing a tidy perl daemon to > handle it and stashing it up on pgfoundry. Or have a look at PGQ which is made to handle this kind of queue processing: http://wiki.postgresql.org/wiki/Skytools http://wiki.postgresql.org/wiki/PGQ_Tutorial http://kaiv.wordpress.com/2007/10/19/skytools-database-scripting-framework-pgq/ Regards, -- dim