So with the release of 5.4 beta, I figured it was worth taking a shot at
porting pl/lua (Lua embedded into PostgreSQL as a server-side language)
Those who have followed the list for the past year know that I have been
objecting to certain issues with 5.4, and so I'd been holding off on
doing any conversion work in the hope that those issues would be
addressed. The result is something of a mixed bag, as detailed below.
1. Stack usage
lua_setcstacklimit() is at least a usable (for me) workaround for the
stack usage problems; I can run (at startup) a Lua chunk that recurses a
known number of times and then calls back to C, use that to estimate the
number of bytes of stack used per level, and divide my target stack
usage by that to get a max recursion depth.
Talking to other Lua users, though, the increased stack usage is
potentially a serious problem. How much is actually being gained by
doing it this way?
2. Taking advantage of <close>
This wasn't too hard, as expected; arranging to reset threads when
aborting execution of a set-returning function rather than just leaving
them for the garbage collector to deal with was fairly trivial.
This as expected was the big problem, and I'm really unhappy with all of
the solutions I came up with.
The biggest problem is that what the lua_WarnFunction can do is so
limited - with no API calls possible, the only way I can even tell
whether the warning might be about a PostgreSQL error rather than a lua
error is to search the warning message for the "object is not a string"
text. If an error that isn't a string is caught in the GC or in <close>
processing, there's no way to know what it is, even in contexts where it
would be safe to emit it as a warning.