> Actually, there is another important case -- the future behavior
> when another system function is defined that conflicts with existing
> user defined functions. If the two sets of functions were in
> different name spaces, there would be no problem. But there is a
> single name space, and both the Firebird problem and users will be
> defining more functions, so a mechanism for handling conflicts is
> necessary.

But the namespaces are neither planned for FB 2.1 nor for FB 3.0
(Vulcan merge). Though I agree that we have to find the way how to
make the upgrade less painfull.

> Yes, absolutely. That is the only way to make the set of system
> functions extensible while maintaining backwards compatibility
> without introducing separate name spaces.
>
> Frankly, I don't think there should be any difference between system
> and user defined functions other than system functions show up
> automatically on Firebird installation or update. A function is a
> function. It shouldn't matter whether it was written by a Firebird
> database developer, bought on the open market, or written by
> customer. Every function has a SQL name, a list parameters, a
> library name, an entrypoint name, and a linkage. Who wrote it,
> where it lives, and what language it was written in is of no
> interest to users. Except for any functions mandated by the
> standard, I challenge anyone to come up with a reason that system
> functions and user functions should have different behaviors.

One of the reasons I see is the performance. Calling a static function
inside the engine which accesses the internal data structures
allocated in the engine should be less expensive than copying data
from internal data structures to the ones we define as standard,
passing them to external entity and unmarshalling the response back to
engine.

Experiments show that invoking the simply
java.lang.System.currentTimeMillis() in our implementation of Java
stored procedures is 2.5 times slower than casting 'now' as timestamp.
And I am pretty sure that our marshalling/unmarshalling is quite
efficient. The call of C++ UDF should be less expensive than calling
Java function (but more expensive than calling internal static
method), and we can't talk about sandboxing.

I am not happy with this approach. I'd say that introducing namespaces
is the correct solution and other solutions that we discussed are only
partial solutions, simple or complex, but they have drawbacks.

So,