From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH] |
Date: | 2010-01-31 01:38:59 |
Message-ID: | 34d269d41001301738w24c8c0ddj6923509ae408f169@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 30, 2010 at 16:16, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> This is an update to the final plperl patch in the series from me.
>
> Changes in the original patch:
plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> - Ensure Safe container opmask is restored even if @EvalInSafe code
> throws an exception.
Maybe we could be a bit smarter about this and avoid the problem? Im
thinking either (for @ShareIntoSafe as well):
1) always reinit @EvalInSafe at the top of plc_safe_ok.pl
our @EvalInSafe = [ ]; ....
Seems like a non-starter, why have the 'our' at all?
2)Change EvalInSafe to be a hash so at least the problem with
duplicates goes away:
$EvalInSafe{'strict'} = 'caller';
Then again maybe its fine the way it is. Thoughts?
This makes me think maybe we should not expose it at all. Its not
like you can tell people oh you have something you need in your plperl
safe? Just stick it in @PostgreSQL::InServer::safe::EvalInSafe. As
we might change this *undocumented* interface in the future.
That being said *im* ok with it. Its useful from a debug standpoint.
Thoughts?
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2010-01-31 02:06:12 | Re: development setup and libdir |
Previous Message | Andrew Dunstan | 2010-01-31 00:55:22 | Re: development setup and libdir |