> > 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.

Well, the LANGUAGE thingy was only there to tell the engine
how to process the actual CREATE and code.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com