Re: plpython implementation

From: Szymon Guz <mabewlun(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpython implementation
Date: 2013-06-30 12:18:07
Message-ID: CAFjNrYtVzpA72vZgdaiLBHM3opG7NZxdw0M4GKLxNG-JRAz4Hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 June 2013 14:13, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 06/30/2013 07:49 AM, Szymon Guz wrote:
>
>> I'm reading through plperl and plpython implementations and I don't
>> understand the way they work.
>>
>> Comments for plperl say that there are two interpreters (trusted and
>> untrusted) for each user session, and they are stored in a hash.
>>
>> Plpython version looks quite different, there is no such global hash with
>> interpreters, there is just a pointer to an interpreter and one global
>> function _PG_init, which runs once (but per session, user, or what?).
>>
>> I'm just wondering how a plpython implementation should look like. We
>> need another interpreter, but PG_init function is run once, should it then
>> create two interpreters on init, or should we let this function do nothing
>> and create a proper interpreter in the first call of plpython(u) function
>> for current session?
>>
>>
>>
>
> python does not any any sort of reliable sandbox, so there is no plpython,
> only plpythonu - hence only one interpreter per backend is needed.
>
>
Is there any track of the discussion that there is no way to make the
sandbox? I managed to create some kind of sandbox, a simple modification
which totally disables importing modules, so I'm just wondering why it
cannot be done.

Szymon

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-06-30 12:30:20 Randomisation for ensuring nlogn complexity in quicksort
Previous Message Andrew Dunstan 2013-06-30 12:13:13 Re: plpython implementation