Re: plpython implementation
От | Szymon Guz |
---|---|
Тема | Re: plpython implementation |
Дата | |
Msg-id | CAFjNrYtVzpA72vZgdaiLBHM3opG7NZxdw0M4GKLxNG-JRAz4Hw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpython implementation (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: plpython implementation
Re: plpython implementation |
Список | pgsql-hackers |
On 30 June 2013 14:13, Andrew Dunstan <andrew@dunslane.net> wrote:
python does not any any sort of reliable sandbox, so there is no plpython, only plpythonu - hence only one interpreter per backend is needed.
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?
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 по дате отправления: