Hello,
someone can tell me if is secure to create external python modules and
import them to functions/procedures/triggers to use?

I am doing the following:

function/procedure/trigger:

CREATE OR REPLACE FUNCTION tabela_be_i_tg_fx() RETURNS trigger AS $body$
from dbfunctions.postgres.pg_trigger import TestTrigger as fx
fe = fx()
return fe.execute(args=TD["args"], event=TD["event"], when=TD["when"],
level=TD["level"], name=TD["name"], relid=TD["relid"], new=TD["new"],
old=TD["old"], pl_py=plpy)
$body$
LANGUAGE plpythonu;


at python module I have:


class TestTrigger(object):
def execute(self, args, event, when, level, name, relid, new, old,
pl_py):
new["group_name"]='__modified__'
return 'MODIFY'


all this works properly (on windows and linux), but I don't know if is
the correct way to use plpythonu, and if I will have future problems.

Another question is that I have read in some discussion list (old
message year 2003) the possibility of plpython be removed from
postgresql, this information is valid yet?

sorry bad English

Thank's for all

--
Alexandre da Silva
Analista de Sistemas - Bacharel em Sistemas de Informação (2003-2007)


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHkK5GAfqZj7rGN0oRAnQTAKCEqj74QpgsI7mquBbIp5 v4GFbmdwCdGqDA
x49fkDHxIgUZK9SJxIbqdhs=
=uNc/
-----END PGP SIGNATURE-----

On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
> plpython !=3D plpythonu.
>
> plpython was the 'secure' sandboxed version. The Python devs gave up
> supporting any sort of sandboxing feature in Python declaring it
> impossib=
> le.

Someone should definitely take a look at this: http://
sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html

That guy claims he's locked down the python interpreter there.

Erik Jones

DBA | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 1/18/08, Erik Jones <erik@myemma.com> wrote:
> On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
> > plpython !=3D plpythonu.
> >
> > plpython was the 'secure' sandboxed version. The Python devs gave up
> > supporting any sort of sandboxing feature in Python declaring it
> > impossib=
> > le.
>
> Someone should definitely take a look at this: http://
> sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html
>
> That guy claims he's locked down the python interpreter there.

Interesting. But the problem has never been in locking down
the interpreter vX.Y, but locking down interpreter vX.Y+1, when
previously work was done on vX.Y. Without upstream developers
cooperation this has been too painful.

So the interesting thing in the posting is not that he succeeded
locking Python down, but that he is pushing the patch to core.

--
marko

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I'm a fan of unsecured languages in the database.
Obviously they should only be used by people who understand the difference.
I wouldn't want python locked down.
That would prevent so many different external functions that can now be integrated into the database.

Among other things that I currently do with plpythonu is a function that reads a template file,
populates it with data and saves the file to the server. It then FTPs the file to another server.
It certainly can all be done outside of the database, but it is so much easier (and less maintenance)
to include it as a function.

Sim


Erik Jones wrote:
>
> On Jan 18, 2008, at 7:48 AM, Stuart Bishop wrote:
>> plpython !=3D plpythonu.
>>
>> plpython was the 'secure' sandboxed version. The Python devs gave up
>> supporting any sort of sandboxing feature in Python declaring it
>> impossib=
>> le.
>
> Someone should definitely take a look at this:
> http://sayspy.blogspot.com/2007/05/i...ng-python.html
>
> That guy claims he's locked down the python interpreter there.
>
> Erik Jones
>
> DBA | Emma®
> erik@myemma.com
> 800.595.4401 or 615.292.5888
> 615.292.0777 (fax)
>
> Emma helps organizations everywhere communicate & market in style.
> Visit us online at http://www.myemma.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

Sim Zacks wrote:
> I'm a fan of unsecured languages in the database.
> Obviously they should only be used by people who understand the difference.
> I wouldn't want python locked down.
> That would prevent so many different external functions that can now
> be integrated into the database.
>
> Among other things that I currently do with plpythonu is a function
> that reads a template file, populates it with data and saves the file
> to the server. It then FTPs the file to another server. It certainly
> can all be done outside of the database, but it is so much easier (and
> less maintenance) to include it as a function.

Having the trusted language does not mean you lose the untrusted one.
We have both plperl and plperlu, for example.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq