PL/Lua (was: plpython implementation)

From: Luis Carvalho <lexcarvalho(at)gmail(dot)com>
To: james <james(at)mansionfamily(dot)plus(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Szymon Guz <mabewlun(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: PL/Lua (was: plpython implementation)
Date: 2013-07-01 22:15:15
Message-ID: 20130701221515.GA7209@saci
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Claudio Freire wrote:
> 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.

<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(at)NO(dot)gmail(dot)SPAM(dot)com"):gsub("(%u+%.)","")))'

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nicholas White 2013-07-01 22:20:40 Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Previous Message Robins Tharakan 2013-07-01 21:52:37 Re: Add more regression tests for CREATE OPERATOR