Re: plpython implementation

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: plpython implementation
Дата
Msg-id CAGTBQpYHihRvEttwad3Ug928KFsJJOj00Hej-vyTjcNDbyQKSA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpython implementation  (james <james@mansionfamily.plus.com>)
Ответы Re: plpython implementation  (Hannu Krosing <hannu@2ndQuadrant.com>)
PL/Lua (was: plpython implementation)  (Luis Carvalho <lexcarvalho@gmail.com>)
Список pgsql-hackers
On Mon, Jul 1, 2013 at 2:29 AM, james <james@mansionfamily.plus.com> wrote:
> On 01/07/2013 02:43, Claudio Freire wrote:
>>
>> In essence, you'd have to use another implementation. CPython guys
>> have left it very clear they don't intend to "fix" that, as they don't
>> consider it a bug. It's just how it is.
>
> Given how useful it is to have a scripting language that can be used outside
> of the database as well as inside it, would it be reasonable to consider
> 'promoting' pllua?
>
> My understanding is that it (lua) is much cleaner under the hood (than
> CPython).
> Although I do recognise that Python as a whole has always had more traction.

Well, that, or you can use another implementation. There are many, and
PyPy should be seriously considered given its JIT and how much faster
it is for raw computation power, which is what a DB is most likely
going to care about. I bet PyPy's sandboxing is a lot better as well.

Making a postgres-interphasing pypy fork I guess would be a nice
project, it's as "simple" as implementing all of plpy's API in RPython
and translating a C module out of it.

No, I'm not volunteering ;-)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: james
Дата:
Сообщение: Re: plpython implementation
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Review: query result history in psql