Re: Add on_perl_init and proper destruction to plperl [PATCH]

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Jan 27, 2010, at 1:53 PM, Robert Haas wrote:
>> What exactly do we mean by "system-level actions"? I mean, END blocks
>> can execute arbitrary code....

> Yeah. In Perl. What part of Perl can access the backend systems without SPI? And that it couldn't do at any other point in runtime?

You still aren't letting go of the notion that Perl could only affect
the rest of the backend via SPI. The point I'm trying to impress on you
is that there are any number of other possible pathways, and that Perl's
historical assumption that it owns all resources of the process make
those pathways a nontrivial hazard. Anything that Perl does to libc
state, open file handles, etc etc carries a high risk of breaking the
backend.

Now it is certainly true that any such hazards can be created just from
use of plperlu (we hope only plperlu, and not plperl ...) today,
without any use of the proposed additional features. What is bothering
me about these features is that their entire reason for existence is to
encourage people to use parts of Perl that have time-extended effects on
the process state. That means that (a) the probability of problems goes
up substantially, and (b) our ability to fix such problems goes down
substantially. Right now, the canonical approach to trying to undo
anything bad Perl does is to save/restore process state around a plperl
call. If we're trying to support usages in which Perl has time-extended
effects on process state, that solution goes out the window, and we have
to think of some other way to coexist with Perl. (Where, I note,
"coexist" means "Perl does what it damn pleases and we have to pick up
the pieces" --- we're not likely to get any cooperation on limiting
damage from that side. Nobody even suggested that we treat stomping on
setlocale state as a Perl bug, for example, rather than a fact of life
that we just had to work around however we could.)

So the real bottom line here is that I foresee this patch as being
destabilizing and requiring us to put large amounts of time into
figuring out workarounds for whatever creative things people decide to
try to do with Perl. I'd feel better about it if I thought that we
could get away with a policy of "if it breaks it's your problem", but
I do not think that will fly from a PR standpoint. It hasn't in the
past.

regards, tom lane