Martijn Tonies wrote:

>Taking External Functions in account, you propose External Procedures,
>but WITH a connection and transaction context. This makes then much
>more powerful, everyone understands that. With it, of course, come certain
>security related issues, but that's a different story.
>

There are always security questions when external code is loaded into
the engine address space and called. I think we just have to accept
this. The question is whether we have to trust loadable code to
implement engine security policy.

I designed the Vulcan JDBC interface (which I hope everyone understands
is written in C++ and has nothing to do with Java other than common
semantics and names) to export two types of connections from an internal
Attachment object. One is a system connection, from which anything and
everything goes, and the other is a user connection, which has exactly
the same security constraints applied as n externally supplied piece of
SQL. A security plugin would use the former; an external function or
procedure the latter. So disregarding the unhappy truth that a piece of
hostile code could rummage around an circumvent any and all security, a
non-malicious, non-devious piece of code presented with a proper user
JDBC connection is as secure as anything else.

>I dare to raise the question: Aren't your proposed External Procedures
>actually internal procedures in a different language?
>

No. Internal procedures have all sorts of services and facilities
available to them. External procedures has a small, well-defined API
that defines everything that it can legitimately do. And because the
external procedure must transcend specific data versions, the API must
be stable, hence isolated from general engine data structures.

>It should be noted, of course, that if you allow them to connect to other
>databases and use transactions actively, or start transactions by their own,
>they are different from the current External Functions.
>

You bet. And if they weren't different, there would be no point in
implementing them (a joke!). But this brings out another important
point. Unlike internal services, an external procedure must be assumed
to have the potential to stall for a day or two, meaning that no engine
resource can be locked over an external procedure call.

There really isn't any point to making rules about what external
procedure can or can't do if you can't enforce the rules, and you
can't. So you must resign yourself to the fact that somebody (ok,
probably everybody) is going to write a procedure that does things you
didn't anticipate.

>Even if they will be "external procedures", can the "external function" API
>be upgraded to the same mechanism?
>

Similar, I think, but not the same. The APIs are, I think, different.
An external function or trigger is invoked with a single call, and
can/should be implemented with the equivalent of a Java static method.
A procedure that is returning rows is called repeativily, and needs a
full object context. But even external functions and triggers need
separate APIs for obvious reasons.

>What languages should be supported? With Vulcan, using the Java
>interface seems logical.
>

Logical is one reason. But since Paul Ruizendaad spent an entire
weekend sweet-talking me into implementing them, he better love them to
pieces...

>With respect to Java, it sure makes things a whole lot easier to port
>external procedures/functions from one platform to the other, while
>currently, with external functions, one needs different compilers
>(Windows, Linux, etc) to compile your libraries...
>

It's no secret that Netfrastructure has a JVM builtin. Java portability
(except anything having to do with AWT) is everything anyone could wish
for. I don't think Netfrastructure has two customers that use the same
Java IDEs. Paul Beach even uses Borlands...

>Perhaps we could continue on your idea(s) and ask the following:
>- extend the current "external" API (with Java interfaces?)
>- bring Java more-or-less into the engine
>

A tame JVM with a consistent license is a starting point, but only a
starting point. The really hard part, believe it or not, is
synchronizing Java object lifetimes, determined by a garbage collector,
with engine object, controlled by reference counts. The connection
owners the statements while own resultsets, programmers under 40 tend
not to close things when they're done with them, and really nasty,
really complex race conditions result.

>Bringing native Java into the engine would be a very powerful
>extension to the current PSQL language, wouldn't it?
>
>

Ah, but in Java-speak, "native" means C or C++!

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376