Re: Fwd: [GENERAL] Procedural Languages

2012-05-31 Thread Darren Duncan

Michael Nolan wrote:

On Thu, May 31, 2012 at 2:23 PM, Darren Duncan  wrote:
Michael Nolan wrote:

PL/pgSQL and PL/perlu are the only ones I use.  I use PL/perlu
primarily to launch shell scripts from triggers, for example to
update an external website when a row in a table has been
inserted, deleted or updated.

There is also another way to do what you describe that might be more
secure.

Rather than having the DBMS launch shell scripts directly, instead
use LISTEN/NOTIFY messaging, where the trigger posts a message, and
you have an ordinary client script listening for them, and the
client script launches the shell scripts when it gets a message.

This way, you need a persistent client script, but you don't need to
invoke the shell in the DBMS ... or use the untrusted version of
PL/Perl if that's all it was for.

Anybody have examples of a persistent client script?


Not a whole one.  But you can make a simple daemon in Perl, either by hand or 
using some CPAN module.


The Postgres-related part though, see 
http://search.cpan.org/dist/DBD-Pg/Pg.pm#pg_notifies for how the client script 
talks to Postgres for this message passing.


Hopefully that'll answer the more interesting part for you.

-- Darren Duncan

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Fwd: [GENERAL] Procedural Languages

2012-05-31 Thread Michael Nolan
-- Forwarded message --
From: Michael Nolan 
Date: Thu, May 31, 2012 at 2:49 PM
Subject: Re: [GENERAL] Procedural Languages
To: Darren Duncan 




On Thu, May 31, 2012 at 2:23 PM, Darren Duncan wrote:

> Michael Nolan wrote:
>
>> PL/pgSQL and PL/perlu are the only ones I use.  I use PL/perlu primarily
>> to launch shell scripts from triggers, for example to update an external
>> website when a row in a table has been inserted, deleted or updated.
>>
>
> There is also another way to do what you describe that might be more
> secure.
>
> Rather than having the DBMS launch shell scripts directly, instead use
> LISTEN/NOTIFY messaging, where the trigger posts a message, and you have an
> ordinary client script listening for them, and the client script launches
> the shell scripts when it gets a message.
>
> This way, you need a persistent client script, but you don't need to
> invoke the shell in the DBMS ... or use the untrusted version of PL/Perl if
> that's all it was for.
>
> -- Darren Duncan
>

Anybody have examples of a persistent client script?
--
Mike Nolan