Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH] - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]
Date
Msg-id 34d269d41001301738w24c8c0ddj6923509ae408f169@mail.gmail.com
Whole thread Raw
In response to Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]  (Tim Bunce <Tim.Bunce@pobox.com>)
Responses Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]
List pgsql-hackers
On Sat, Jan 30, 2010 at 16:16, Tim Bunce <Tim.Bunce@pobox.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?


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: development setup and libdir
Next
From: Ivan Sergio Borgonovo
Date:
Subject: Re: development setup and libdir