Re: Trusted plperl

From: Joel Burton <jburton(at)scw(dot)org>
To: msteele(at)inet-interactif(dot)com
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trusted plperl
Date: 2001-04-20 21:33:13
Message-ID: Pine.LNX.4.21.0104201729570.5655-100000@olympus.scw.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 20 Apr 2001 msteele(at)inet-interactif(dot)com wrote:

> Hey folks, I sent out this question a while back without
> ever getting an answer, so here I go again :)
>
> Has anyone managed to compile a trusted plperl interpreter
> into postgres? The Opcode stuff which blocks the use of
> external modules, and 99% of perl's built-in operators
> really bugs me :(
>
> Since my postgres installations will never be accesible by
> end-users, there are no risks for me to set up a fully trusted
> interpreter. I think that if I could use perl's full power
> from inside postgres I could make it do some very impressive
> things and might simplify some application development.
>
> I would be more than glad to hack the code myself, but I very
> little C. It would be amazing to be able to import abitrary perl
> modules straight into a stored functions for those of us
> who don't need the extra security that using Opcode provides.
>
> As a side note, the Opcode doesn't really provide that
> much security to the imbedded interpreter. Some of the functions
> which are allowed by the current setup can be easily used
> to crash a system (for example, a badly built regular expression
> with backreferences can eat up all available memory in seconds).

(re: the securyti point... there's still a big difference IMHO between
letting people construct memory-murdering regexes and letting them execute
*any arbitrary perl code*, though)

Sorry, no clue how to do this w/plperl.

Without starting a perl/python war (yawn!), if you're python-saavy,
there's a beta-quality release of plpython out there, and this
(a) includes query/trigger/etc support, and (b) is easily modifying so
that additional modules can be loaded above and beyond those included with
the standard distrib.

So, who's going to write pl/visualbasic and pl/logo? ;-)

--
Joel Burton <jburton(at)scw(dot)org>
Director of Information Systems, Support Center of Washington

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mikheev, Vadim 2001-04-20 22:11:29 RE: Best practice
Previous Message Joel Burton 2001-04-20 21:29:00 problem with sorting (fwd)