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:

Previous
From: Robins Tharakan
Date:
Subject: Re: Add more regression tests for CREATE OPERATOR
Next
From: Nicholas White
Date:
Subject: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls