Re: plpython implementation - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: plpython implementation
Date
Msg-id CAGTBQpYHihRvEttwad3Ug928KFsJJOj00Hej-vyTjcNDbyQKSA@mail.gmail.com
Whole thread Raw
In response to Re: plpython implementation  (james <james@mansionfamily.plus.com>)
Responses Re: plpython implementation
PL/Lua (was: plpython implementation)
List 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 by date:

Previous
From: james
Date:
Subject: Re: plpython implementation
Next
From: Pavel Stehule
Date:
Subject: Re: Review: query result history in psql