Re: plpython implementation - Mailing list pgsql-hackers

From Szymon Guz
Subject Re: plpython implementation
Date
Msg-id CAFjNrYtVzpA72vZgdaiLBHM3opG7NZxdw0M4GKLxNG-JRAz4Hw@mail.gmail.com
Whole thread Raw
In response to Re: plpython implementation  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: plpython implementation
Re: plpython implementation
List pgsql-hackers
On 30 June 2013 14:13, Andrew Dunstan <andrew@dunslane.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 

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: plpython implementation
Next
From: Atri Sharma
Date:
Subject: Randomisation for ensuring nlogn complexity in quicksort