Re: plpython implementation

On Mon, Jul 1, 2013 at 2:29 AM, james <james(at)mansionfamily(dot)plus(dot)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 ;-)