"David E. Wheeler" <da...@kineticode.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers