Can we still trust plperl? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Can we still trust plperl?
Date
Msg-id 4B98FED2.4040007@dunslane.net
Whole thread Raw
Responses Re: Can we still trust plperl?
Re: Can we still trust plperl?
Re: Can we still trust plperl?
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: strk
Date:
Subject: Re: Dyamic updates of NEW with pl/pgsql
Next
From: Tom Lane
Date:
Subject: Re: operator exclusion constraints