Subject | Re: External procedures: call for discussion |
---|---|
Author | paulruizendaal |
Post date | 2004-04-01T17:58:02Z |
Re:
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 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.
Paul
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 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.
Paul