Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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: 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
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.


In response to


pgsql-hackers by date

Next:From: Ivan Sergio BorgonovoDate: 2010-01-31 02:06:12
Subject: Re: development setup and libdir
Previous:From: Andrew DunstanDate: 2010-01-31 00:55:22
Subject: Re: development setup and libdir

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group