Roman Rokytskyy wrote:

>
>The only thing that might become visible to user and that was
>discussed here is the fact, that one implementation proposal has a
>side effect which allows user to "re-define" the function. In other
>words, if we have sytem function LOWER(), in first case user was able
>to define his own implementation of this function, i.e. something like
>this:
>
>DECLARE EXTERNAL FUNCTION LOWER CSTRING(1024)
>RETURNS CSTRING(1024)
>ENTRY_POINT 'upper'
>MODULE_NAME 'my_wrong_udf';
>
>Note, I have intentionally used the function name LOWER and the entry
>point name 'upper'. Clear, I prefer the second solution, where
>"system-defined functions" cannot be overriden by the user.
>
>

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.

>As to what you have said about the requirements, sandbox languages,
>configuratio files, etc. - that sounds very correct, but it belongs to
>another discussion, which we will have here sooner or later.
>
>

Architecture is the art of solving all of the problems at the same
time. It doesn't mean that all aspects need to implemented at same
time, just that all problems have been considered and addressed.

I really don't like the idea that part of a problem can be solved. If
the full solution isn't understood, how can you be sure that a partial
solution doesn't make a complete solution more difficult or even impossible?

The core question is how the function name space is managed. Treating
that as nothing more than an implementation artifact is the programmng
equivalent to painting yourself into a corner.

>
>
>P.S. Just came to my mind: can it be that you suggest to make the list
>of available system-defined functions (e.g. functions that are
>available without declaration) configurable on per-database level and
>provide a possibility to implement them in different languages?
>
>
>

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.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376