Re: [PATCHES] WIP 2 interpreters for plperl - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCHES] WIP 2 interpreters for plperl
Date
Msg-id 4563078A.1060503@dunslane.net
Whole thread Raw
In response to Re: [PATCHES] WIP 2 interpreters for plperl  ("Jim Buttafuoco" <jim@contactbda.com>)
List pgsql-hackers
Martijn van Oosterhout wrote:
> On Mon, Nov 20, 2006 at 04:14:34PM -0500, Andrew Dunstan wrote:
>   
>> Jim Buttafuoco wrote:
>>     
>>> I might be one of the ones who depends on the same interpreter.  In your 
>>> new
>>> scheme, the _SHARED hash will only be shared between like interpreters,
>>> correct?  This is going to force me to switch all of my perl code to use 
>>> the
>>> plperlu interpreter :(
>>>       
>> Yes. Sorry, but I can't see any way around it. If anyone can suggest one 
>> then speak up loudly ASAP.
>>     
>
> Since the stuff plperlu should be small and self contained, you just
> need to set it up so all the data needed by the plperlu function is
> passed as a parameter. I suppose we'd need to look at the use case to
> see if this is a real obsticle.
>
> I suppose you're not permitted to call other perl functions directly
> with \%_SHARED as a parameter, right?
>
>
>   

\%_SHARED only has meaning in the context of a given perl interpreter. 
If we use it in another interpreter it will point to the middle of 
nowhere. It's the equivalent of one program passing a pointer to another 
program. I thought of playing clever games with a tied interface 
(perldoc perltie for more info), but then we'd still have troubles with 
things like:

my $xxx=2;
$_SHARED{foo} = { bar => [1,2,3], baz=> sub { return ++$xxx; } };

The only thing I have seen that looked remotely promising is the 
non-standard Safe::World module, which if it lives up to its promise 
might allow us to go back to using a single interpreter. But I have not 
had time to investigate further, and I don't thing we can rely on a 
module almost no standard installation will have, unless we want to ship 
it ourselves. It doesn't seem to have been worked on since 2004. It is 
certainly too late to think of anything like that for 8.2, I think - it 
would need significant analysis and testing which I do not currently 
have time for, and release is just around the corner, we fervently hope.

cheers

andrew



pgsql-hackers by date:

Previous
From: Russell Smith
Date:
Subject: Re: Statistics visibility in SERIALIZABLE transactions
Next
From: Martijn van Oosterhout
Date:
Subject: Re: [PATCHES] WIP 2 interpreters for plperl