Re: [PATCHES] WIP 2 interpreters for plperl

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Jim Buttafuoco <jim(at)contactbda(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] WIP 2 interpreters for plperl
Date: 2006-11-21 14:04:58
Message-ID: 4563078A.1060503@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-21 14:29:38 Re: Custom Data Type Question
Previous Message Simon Riggs 2006-11-21 11:49:20 Re: quick review

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-21 14:53:36 psql environment doc addition
Previous Message Martijn van Oosterhout 2006-11-21 10:13:57 Re: [PATCHES] WIP 2 interpreters for plperl