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