First of all, I have to say that I have read your "follow-up" post.

> Returning to my original point, take the time to list and debate the
> requirements for UDFs. Deciding whether or not local UDFs should
> override system UDFs by which implementation you prefer is ass
> backwards. Figure out which behavior you want first, then design an
> implementation that meets the requirements.

I guess you have mixed something. We were not talking about UDFs,
which are _user_-defined functions. We are talking about the functions
provided by the engine to the user and do not require any additional
declaration on the database level (e.g. already existing UPPER()
function).

In this case, the way data are passed to the function implementation,
if and how the callback happens and so on is not interesting to the
user. We can change the mechanism with each point release, nobody will
notice anything as long as the function does the same. Also the
decision about the C, C++, Java, Python and so on does not apply here
- these functions are to be implemented in the language in which the
engine is written.

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.

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.

Roman

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?