Can we still trust plperl?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Can we still trust plperl?
Дата
Msg-id 4B98FED2.4040007@dunslane.net
обсуждение исходный текст
Ответы Re: Can we still trust plperl?  (Kenneth Marshall <ktm@rice.edu>)
Re: Can we still trust plperl?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Can we still trust plperl?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: strk
Дата:
Сообщение: Re: Dyamic updates of NEW with pl/pgsql
Следующее
От: Tom Lane
Дата:
Сообщение: Re: operator exclusion constraints