PL/Lua (was: plpython implementation) - Mailing list pgsql-hackers
From | Luis Carvalho |
---|---|
Subject | PL/Lua (was: plpython implementation) |
Date | |
Msg-id | 20130701221515.GA7209@saci Whole thread Raw |
In response to | Re: plpython implementation (james <james@mansionfamily.plus.com>) |
Responses |
Re: PL/Lua (was: plpython implementation)
|
List | pgsql-hackers |
Hi all, 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. I bet PyPy's sandboxing is a lot better as well. <snip> I think that 'promoting' PL/Lua would be too early, but it'd be a great addition. The latest version, for instance, can run LuaJIT which has a FFI (check the example in "Anonymous Blocks" at PL/Lua's docs.) I think there are two main problems: finding maintainers in the core, and lack of popularity to warrant its promotion (the two problems are related, of course.) Peter Eisentraut wrote: > On 7/1/13 1:29 AM, james wrote: > > 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? > > You can start promoting pllua by making it work with current PostgreSQL > versions. It hasn't been updated in 5 years, and doesn't build cleanly > last I checked. > > Having a well-maintained and fully featured pllua available would surely > be welcome by many. Thanks for the feedback. Actually, PL/Lua's latest version (1.0) was out one month ago, http://pgfoundry.org/frs/?group_id=1000314 but the previous version took around 4 years. I was waiting for bug reports, since I deemed PL/Lua to be fairly featured, but I have now declared it "stable". The project is maintained -- I don't know how to say when something is well-maintained, but small frequency of code updates is not one of my criteria; Lua, for instance, took six years between versions 5.2 and 5.1. BTW, just out of curiosity, when was the last time PL/Tcl was updated? I think that the project is also fully featured, but I'd appreciate any comments on the contrary (that is, feature requests.) I might be mistaken, but PL/Lua has all the features that PL/Python, PL/Perl, and PL/Tcl have, but, for example, features a trusted flavor when PL/Python does not, and has proper type mappings, which PL/Perl does not (everything is translated to text.) PL/Lua 1.0 adds anonymous blocks and a TRUNCATE trigger, and it should run on PostgreSQL 9.2. It can be used with Lua 5.1, 5.2, and LuaJIT 2.0 (if you want speed and an easy C interface through a FFI, you should try LuaJIT!) I'd like to take this opportunity to kindly ask the PostgreSQL doc maintainers to include PL/Lua in the table at Appendix H.3: Name: PL/Lua Language: Lua Website: http://pgfoundry.org/projects/pllua/ Cheers, Luis -- Computers are useless. They can only give you answers. -- Pablo Picasso -- Luis Carvalho (Kozure) lua -e 'print((("lexcarvalho@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
pgsql-hackers by date: