On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
<david.whee...@pgexperts.com> wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
>initialized. And then local()'ly restore them in the plperl entry points.
>Should only be a few lines of code - in theory :)
Basically when we go to compile a new plperl sub we would 'break' out
of the safe, compile the sub (which it itself would go back into the
safe) and then because we local()ly set/restore we would be reset to
the same context when we returned.
Not only is there some prior art for this method (Safe::Hole). After
playing with it a bit last night I agree it should be fairly small and
simple. Im a bit worried there might be some corner cases. All the
easy ones I see cant happen with plperl only with arbitrary 3rd party
modules. Things we might need to do in addition would be: ignoring
END blocks, saving PL_curstash, Invalidating the ISA and method
caches, saving/restoring INC... And that would only be because im
worried there might be some strange issues with the new
plperl.plperl_init. Its hand waving at this point.
Another way I played with last night is calling
Opcode::_save_call_sv("main", Opcode::full_ops, sub_to_compile)
directly instead of perl_call_sv() to compile the sub (or in
pl/plperl.c plperl_create_sub replace the call to perl_call_sv with
Opcode::_safe_call_sv). It should be even simpler and safer. We
would still need to save and local() a few things... But it should
work.
Anyway, im hoping to look at this more tonight... My lunch is over :)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
