lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>>>>> "Patrick" == Patrick Donnelly <batrick@batbytes.com> writes:

 Patrick> Yields can be converted into errors (and caught) fairly
 Patrick> easily:

That makes a good concrete example actually. Suppose the user does
something like this, replacing words in a string with words looked up
via an SQL query:

CREATE FUNCTION subst_words(str text) RETURNS text LANGUAGE pllua AS $$
    return str:gsub("%w+",
                    function(w)
                      local nw = spi.execute([[ SELECT newword
                                                  FROM replacewords
                                                 WHERE oldword=$1 ]], w)
                      return nw and nw[1] and nw[1].newword
                    end)
$$;

Right now, if spi.execute gets an error generated by PG, what happens is
that it stores the relevant details in a userdata, throws that as a Lua
error, lets it propagate out to the lua_pcall that was used to call the
function, and then raises it as a PG error again. There could be several
levels of this - for example, the SQL query might contain a call to
another Lua function. (It doesn't matter if the error gets replaced with
a different error along the way, for example if we get an out-of-memory
when trying to copy error data, as long as it continues to propagate as
an error and as long as we're not executing arbitrary Lua code.)

I can be sure this is safe because the Lua code can't interfere with the
error process except by calling pcall()/xpcall(), which I already
replaced with my own versions.

But in the new version, as far as I can tell, I can either use a
coroutine - which in the above example means I can't unwind the C stack
safely thanks to the gsub call - or stick with the existing model, in
which case I have to expect that arbitrary Lua code can be executed
during error handling, with no way for me to control what's happening.

-- 
Andrew.