Martijn,

M> First, I think - and I guess we should start that - we should drop the name
M> "UDF".

it would be good but it isn't hurting right now weither.

M> It's NOT an UDF, it's an "External Function", without a connection
M> and transaction context.

Amen.

M> An UDF would be:

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

that would rather be a "stored function", according to common DBMS parlance.
I like the terms "user defined" more than I like "stored", but I like
coherence the most, and since we have stored procedures...
To achieve stored functions, BTW, we only miss syntax, AFAIU.

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

As I understand, they're more like current UDFs with more context
information and a way to call back into the engine. They are
"external" in that they are pluggable and not stored inside a database
like stored procedures and functions are. I guess both the external
and the stored approaches have their merits.

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

that's a good topic to discuss. From what I have read in the past I
have developed the opinion that if Firebird has to talk to Java it
should better do it through an internal, optimized, lean JVM.
Thios does not rule out the concept of external, pluggable procedures
developed in other languages. Now that I think of it, perhaps the
"internal" JVM could be made pluggable and stay optimized at the same
time...

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

That would be terrific!

Ciao
--
Nando Dessena
mailto:nandod@...