| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-26 21:59:14 | Re: plperl/plperlu interaction |
| Previous Message | Tom Lane | 2006-10-26 21:37:47 | Re: GUC description cleanup |