Can we still trust plperl?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Subject: Can we still trust plperl?
Date: 2010-03-11 14:31:46
Message-ID: 4B98FED2.4040007@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-03-11 14:39:31 Re: operator exclusion constraints
Previous Message strk 2010-03-11 14:27:23 Re: Dyamic updates of NEW with pl/pgsql