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  (Martijn van Oosterhout <kleptog@svana.org>)
Re: plpython implementation  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: plpython implementation
Следующее
От: Atri Sharma
Дата:
Сообщение: Randomisation for ensuring nlogn complexity in quicksort