Subscribed unsubscribe Subscribe Subscribe

PL/v8 Road Map

For the last couple of months, I'm back to the PL/v8 development. One reason is that I'm now more interested in building and running a mid-term software project than hacking PostgreSQL core. I found myself enjoying to write the code of PL/v8 as V8's code base is so neat as well as PostgreSQL's. Unfortunately, V8 as a project is a bit closed, so the details on the design, its intention, or the behavior is sometimes vague, which takes me a little long to get an idea.

The goal of PL/v8 is clear. The fact that JavaScript is a pure language that doesn't have external modules in itself actually helps much in the database context. In contrast to PL/perl or PL/python, PL/v8 must be a purely trusted language. What this means is that I don't want to add untrusted features like loading modules from the file system (even pure js files.) The language capability should be completely within the database box and never goes out of it. Someone demands things like node.js, but node.js is now a platform that has npm repository, so the PL/node should come after PL/v8 (I'd think of PL/coffescript since it's only a source-source transformation, but that's another story :)).

Today I added plv8.find_function() to the master branch. This utility function returns a JavaScript function that is registered as a plv8 function. An example explains more than I.

CREATE FUNCTION callee(a int) RETURNS int AS $$
  returns a * a;
$$ LANGUAGE plv8;

CREATE FUNCTION caller(a int) RETURNS int AS $$
  var func = plv8.find_function("callee");
  return func(a);
$$ LANGUAGE plv8;

SELECT caller(2);
 caller 
--------
      4
(1 row)

This way I'd say "no" to users who demand to load external js files from the file system. I agree that the code reuse is a key solution for a good code management practice, i.e. DRY. I'd say PL/v8 has been a toy in that it had had no capability to reuse the code. And it does now.

Of course this is not complete. First, I don't like its name. Anyone has better idea please tell me. Second, the performance is not good. Well, actual code compilation time is not so bad thanks to the fastest JavaScript engine, but find_function is a pure JS function and it's called on every row. One idea to avoid this is that PL/v8 can cache the found functions internally and transparently returns from it. The other is to let a function-local object be "this" of the function and to ask users to cache the function object to "this". Both ways are not trivial, but I'd rather like the latter as the architecture, since the success story around JavaScript wrapper application is a "thin" wrapper as a C/C++ and make another JS layer that handles this kind of annoyance. Even V8 engine implements most of the built-in function by JavaScript.

The other things in my mind for the rest of PL/v8 to be out of the door as the production level include fixing known issues around SPI/triggers, registering to PGXN, Windows binary, and ... tell me what you want.

Remove all ads