Nando, all,

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

Well, our UDFs really are external functions :-)

MSSQL is using UDF for CREATE FUNCTION. Personally, I'd
call them Stored Functions as well. But at least MSSQL is calling
External Procedures really External Procedures :-D

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

Agreed.

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

Not only that - Stored Function need to be parsed in SQL as well. Currently,
they clash with External Functions too. So a bit of syntax and a bit of
parser
changes should do it, 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.

Depending on the language used, these can be stored or external, I think.
For example, if you bring Java into the engine, perhaps the source code
can be stored, instead of "just" the declaration, while bringing several
external procedures, you can declare an external procedure/function
like you're doing now, but say, eg:

DECLARE EXTERNAL { FUNCTION | PROCEDURE } ...
[LANGUAGE { JAVA | STANDARD } ]
etc
and make the "module" a Java class etc... You get the idea.
Standard would be shared library (dll/so), while JAVA would,
obviously, use the [internal] JVM to execute it.

This would be an external function/procedure as opposed to
stored Java procedures/functions.

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

With regards,

Martijn Tonies