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: Andrej Ricnik-Bay <andrej(dot)groups(at)gmail(dot)com>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Jeff Trout <threshar(at)real(dot)jefftrout(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plperl/plperlu interaction
Date: 2006-10-26 21:45:09
Message-ID: 45412C65.1040504@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>   
>> You can also examine the output from perl -V
>>     
>
> I think we've already established that we won't be able to ignore the
> case of not having support for multiple perl interpreters :-(
>
> So it seems we have these choices:
>
> 1. Do nothing (document it as a feature not a bug)
>
> 2. Support separate interpreters if possible, do nothing if not
>    (still needs documentation)
>
> 3. Support separate interpreters if possible, refuse to run both plperl
>    and plperlu functions in the same backend if not.
>
> Any other compromises possible?
>
>   

How would we decide which wins in the third case? "first in" seems 
rather arbitrary. If we went that way I'd probably plump for just 
plperlu to be allowed. The the worst effect would be that the functions 
would have to be created by the superuser. It would be a great pity, of 
course - this threatens to do horrible things to portability ;-(

I guess another possibility would be to allow 3 to be overridden by a 
switch to become 2.

cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-10-26 21:59:14
Subject: Re: plperl/plperlu interaction
Previous:From: Tom LaneDate: 2006-10-26 21:37:47
Subject: Re: GUC description cleanup

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