Hi Roman,

I'm not an egine developer, but I hope I'm allowed to comment anyway,
from the point of usability etc...

> With this post we would like to initiate a discussion about so called
> "external" stored procedures.
>
> Eugeney Putilin is working on Java stored procedures based on JayBird (I

am

> participating in this work as JayBird developer). His development is on
> pretty advanced stage, it is already possible to call arbitrary static

Java

> methods as Firebird procedures and functions, code supports automatic
> parameter conversion, etc. Selectable procedures are not yet supported,

but

> he's working in that direction.
>
> Also during development we were actively communicating with Paul

Ruizendaal

> (he works on PL/SQL interpreter for Firebird) and it became obvious that

if

> we want both PL/SQL and Java SPs in Firebird, some kind of "plug-in" API

is

> needed. I dare to call presented paper a "result of our cooperation",
> leaving a possibility for Paul to disagree with some ideas presented in

it.

First, I think - and I guess we should start that - we should drop the name
"UDF". It's NOT an UDF, it's an "External Function", without a connection
and transaction context.

An UDF would be:

CREATE FUNCTION <name> RETURNS <valid_datatype>
AS
BEGIN
END

Etc...

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.

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

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.

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

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

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

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

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

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com