On Thu, Mar 11, 2010 at 09:31:46AM -0500, Andrew Dunstan wrote: > > 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 > The DBA can do what ever he wants to do to subvert the system up to installing hacked versions of any other "trusted" language so I do not see much of a distinction. We already provide many other foot-guns that may be used by the DBA. pl/perl is very useful as a trusted language but I am certainly for fleshing out the features in other pl-s.
Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
