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

Re: plperl/plperlu interaction

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plperl/plperlu interaction
Date: 2006-10-26 19:15:00
Message-ID: 45410934.8070703@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Dunstan wrote:
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>  
>>> Anyway, it is probably not expected by many users that loading a 
>>> module in plperlu makes it available to plperl  - I was slightly 
>>> surprised myself to see it work and I am probably more aware than 
>>> most of perl and plperl subtleties.
>>>     
>>
>> I think that is a bug and needs to be fixed.  We have the precedent of
>> pltcl, which uses separate interpreters for pltcl and pltclu for exactly
>> this reason.
>>
>>   
>
> Fair enough.
>
> I am not sure what our release timetable is - and presumably this 
> should also be backpatched if we regard it as a bug. I won't be able 
> to do much on this front for the next 2 weeks at least.
>

There is one other wrinkle, that has just come to my attention courtesy 
of Andrew(at)SuperNews(dot) This is what the perlembed man page says:

       Now suppose we have more than one interpreter instance running at the
       same time.  This is feasible, but only if you used the Configure 
option
       "-Dusemultiplicity" or the options "-Dusethreads -Duseithreads" when
       building perl.

Now my local perl (FC5/ia64) has usemultiplicity defined. I am not sure 
how common this is.

Perhaps people who use other platforms could look for these flags in the 
output of
    perl -e 'use Config qw(myconfig config_sh config_vars config_re); 
print config_sh();'

cheers

andrew




In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-10-26 19:23:22
Subject: Re: plperl/plperlu interaction
Previous:From: Tom LaneDate: 2006-10-26 19:07:03
Subject: Re: Nasty btree deletion bug

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