On 07/01/2013 07:53 AM, Claudio Freire wrote:
> 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.
OTOH, pypy startup time is bigger than CPython. It is also generally
slower at running small on-call functions before JIT kicks in.
> I bet PyPy's sandboxing is a lot better as well.
pypy sandbox implementation seems to be a sound one, as it
delegates all "unsafe" operations to outside controller at bytecode
level. The outside controller usually being a standard CPython wrapper.
Of course this makes any such operations slower, but this is the price
to pay for sandboxing.
> 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.
I have some ideas about allowing new pl-s to be written in pl/pythonu
If any of you interested in this are at Europython come talk to me about
this after my presentations ;)
> No, I'm not volunteering ;-)
Neither am I, at least not yet
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ