> M> DECLARE EXTERNAL { FUNCTION | PROCEDURE } ...
> M> [LANGUAGE { JAVA | STANDARD } ]
> M> etc
> M> and make the "module" a Java class etc... You get the idea.
>
> Yes! This is similar to how DB2 does it and I think that it is a
> good idea.
>
> The key here is to separate relational execution ("EXE module",
> a.k.a "looper") from procedural execution (PSQL, Java, PL/SQL,
> etc.). The engine could contain a Java VM to deal with
> procedures/functions in Java (or Jython, or ...) and a specialised
> VM to deal with PSQL (and PL/SQL, TSQL, etc.). Perhaps the JVM can
> handle it all, although the specialised VM will be almost trivial if
> we have SQL inside the engine.

I second the idea of separating relational execution and procedural
execution (basically, that's what paper is about), however I'm against
the proposal that engine knows in what language it is written (it is
implied by syntax "LANGUAGE {JAVA | STANDARD | ...}). This would mean
that extending engine with new language requires changes in the engine
itself, potentially introducing new bugs.

That's why paper contains concepts of module and module factory that
use symbolic identifiers ('JAVA', 'PSQL', etc.). You can view a module
as some kind of very specialized VM capable of handling procedure
calls. How the module does this, is problem of the module itself. It
might delegate call to some other executor, it might interpret call
itself.

> I would recommend that next to these "safe" VM's, we still allow
> calls to external compiled libraries and/or VM's. Rather than
> calling within the same process, it would be better if we used some
> sort of IPC/messaging mechanism to execute potentially "unsafe" code
> in a different process.

I would allow module to execute within the engine's process. IPC might
be a performance bottleneck in some situations.

Roman