
PL/Lua: Lua as a loadable procedural language for Postgres - tosh
https://github.com/pllua/pllua
======
usgroup
Except don’t use this one.

It’s buggy and forgotten.

Use:

[https://github.com/pllua/pllua-ng](https://github.com/pllua/pllua-ng)

Rewritten, much better and actually updated.

------
xdanger
If you want a modern version of this, you should checkout
[https://github.com/RhodiumToad/pllua-
ng](https://github.com/RhodiumToad/pllua-ng)

A friend of mine benchmarked different pl languages and
[https://github.com/eugwne/pllj](https://github.com/eugwne/pllj) was basically
the fastest, but it's not so actively maintained. pllua-ng with luajit 2.1 was
also faster than plv8. But that was about two years ago, your milage may vary.

"Lua is faster - PL/V8 is lightly faster than Python, but Lua is about 30%
faster than PL/V8" \- Pavel Stěhule and that was without luajit, but 4 years
ago.

Maybe someone should build a benchmark :D

~~~
massaman_yams
These are both up to date at the moment, but it's not entirely clear which one
of these will be used for future development:

[https://github.com/RhodiumToad/pllua-
ng](https://github.com/RhodiumToad/pllua-ng) [https://github.com/pllua/pllua-
ng](https://github.com/pllua/pllua-ng)

------
jarym
Looking at these great PL* languages makes me wonder if it would be feasible
to use something like GraalVM to write PL functions in R/Java/JS/etc.

Oracle DB supports this already (it seems, I've not tried it):
[https://www.graalvm.org/docs/examples/mle-
oracle/](https://www.graalvm.org/docs/examples/mle-oracle/) ) - and the
advantage of Graal is it supports a wide range of languages and can output
native binaries.

~~~
rufugee
There's already pljava
([https://github.com/tada/pljava](https://github.com/tada/pljava)) for
java....we use it extensively where I work.

~~~
fusiongyro
How much fun is that?

------
areski
For interest, here a post that show a quick comparison of PLPGSQL, PLLua &
PLV8 [https://www.newfies-dialer.org/using-lua-in-postgresql-
pllua...](https://www.newfies-dialer.org/using-lua-in-postgresql-pllua/)

~~~
xdanger
I quickly redid the benchmarks:
[https://gist.github.com/xvaara/df0b802b86d2aa4f30b88a3fd6b69...](https://gist.github.com/xvaara/df0b802b86d2aa4f30b88a3fd6b69a14)

------
jihadjihad
This looks really cool--reminds me of the capabilities of Redis with Lua
scripts. Does anyone know how it compares to PLV8
([https://github.com/plv8/plv8](https://github.com/plv8/plv8))?

~~~
massaman_yams
Or Tarantool.

------
pmarreck
This is neat. Anyone know of any functional languages that would integrate
with Postgres?

~~~
wmfiv
Scala and Clojure should run under pljava. Probably not a lot of people doing
that though!

------
a_t48
On a game I worked on, we used little snippets of lua in our UI for both
labels and property values (as well as our scripting language). It was very
akin to working with something like HTML+JS. Super convenient.

------
brightball
That's interesting. For somebody who's not all that familiar with Lua, what
are it's main selling points for something like this?

~~~
dustingetz
If you take this idea a lot farther - imagine your entire application —
frontend, backend, web-service, views — can run as a stored procedure inside
the database, and thus load data so fast that it opens up new architectural
possibilities beyond client/server. That sounds like crazyland for people from
the postgres/rest mindset, but it starts to become possible when you have a
simple and portable language that runs in many places.
[http://www.dustingetz.com/:stu-halloway-datomic-ions-in-
seve...](http://www.dustingetz.com/:stu-halloway-datomic-ions-in-seven-
minutes/)

~~~
nisanharamati
Stored Proc biz-logic architecture was a big thing in the 2000s. MSSQL with
its T-SQL were very common (and its polymorphic AND multi-table return types,
could make for some very interesting control flows sometimes). There was a lot
of bitterness about it back in the late 00's and early 10's, and it drove a
lot of ORM adoption.

I worked for a shop in the late 00's and early 10's that had Very Big Database
Servers doing several hundred million transactions per second (100+ core,
multiple RAMSan, etc. type bare metal servers), and stored procs were the way
the go. They were basically the interface layer to the data, and it allowed us
to keep the interface (or even version it) but change how access happened
behind the scenes, like splitting a table into partitions, or replacing a bad
performing query with a differently structured one that did better, which made
it a non-concern for the frontend code that was responsible for getting data
and formatting it, and didn't really care about _how_ that data was retrieved.

