Prev: Assertion failure twophase.c (2) (testing HS/SR)
Next: Can we still trust plperl?
From: Andrew Dunstan on 11 Mar 2010 09:31

Last night my attention was drawn to this:

<http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm>

I'm wondering if we can reasonably continue to support plperl as a
trusted language, or at least redefine what "trusted" actually means.
Does it mean "can't do untrusted operations" or does it mean "can't do
untrusted operations unless the DBA and/or possibly the user decide to
subvert the mechanism"? To me, the latter doesn't sound much like it's
worth having. Is it?

There are a few places where plperl has an advantage over plpgsql, e.g.
code that uses lots of regexes and use of variable to access records
dynamically, so losing it might be a bit of a pain. Of course, there
would still be plperlu, with the downside that the functions have to be
installed by a superuser. One of my PGExperts colleagues told me his
reaction was "Well, I might just as well use plperlu", and that pretty
well sums up my reaction.

Of course, another thing is that it might spur either building of some
of the missing stuff into plpgsql, or addition of another language that
is both safe and which supports them, like say PL/JavaScript.

Thoughts?

cheers

andrew

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

 | 
Pages: 1
Prev: Assertion failure twophase.c (2) (testing HS/SR)
Next: Can we still trust plperl?