Re: Package namespace and Safe init cleanup for plperl UPDATE 3 [PATCH]

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?

In response to

Responses

Browse pgsql-hackers by date

  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