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
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) |