From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Alex Hunsaker <badalex(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Date: | 2010-01-28 00:37:22 |
Message-ID: | BC68C490-A8F1-463E-A6F1-CD0B034F5949@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 27, 2010, at 4:33 PM, Tom Lane wrote:
> [ shrug...] I see little point in repeating myself yet again.
> It's obvious that the people who want this are entirely willing
> to adopt a Pollyanna-ishly optimistic view about its potential
> to cause serious problems that we may or may not be able to fix.
Well, no. The problems you raise already exist in plperlu. And I would argue that they're worse there, as the DBA can give others permission to create PL/PerlU functions, and those users can do all kinds of crazy shit with them. on_perl_init can be executed the DBA only. It's scope is far less. This is *safe* than PL/PerlU, while given more capability to PL/Perl.
> I don't really expect to be able to prevent something along this line
> from getting committed --- I'm merely hoping to circumscribe it as much
> as possible and get large WARNING items into the manual's description.
Oh, absolutely. Your sober attention to security issues is greatly appreciated by us fanboys.
Best,
David
PS: I'm a PostgreSQL fanboy, not a Tom Lane fanboy. ;-P
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-01-28 00:45:07 | Re: Review: listagg aggregate |
Previous Message | KaiGai Kohei | 2010-01-28 00:37:19 | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns |