Hello, Antonio!

Wednesday, October 13, 2004, 7:49:39 PM, you wrote:

AM> I guess the problem can be that if someone needs to restart a
AM> server, this functions will not be loaded automaticaly and you can
AM> have a lot of databases that use this functions. Applications will
AM> not run properly until they are registered.

? udfs are nothing related with restarting server.
UDF dlls (so) are loaded automatically if some query calls
declared udf. UDF declaration remains in database forever,
until you "drop external function".

So I don't understand what you are talking about.

AM> I suppose there is also some overhead caused by external calls than
AM> might slow down the server as well. A lot of functions are very

You wrong, there is almost nothing that slowdowns UDF dll call.

AM> commonly used, why not integrate them to the engine?, and still be
AM> able to register other functions not commonly used as UDFs.

This question was often discussed in past. Yaffil, for example,
have lot of SDF functions inside engine. But this is lot of work,
and I don't know what SDFs will be moved from Yaffil code to Firebird.

AM> I would incorporate these funtion because they are very commonly
AM> used:

AM> And move the rest of the 'ib_udf' functions to a 'Trig_udf'
AM> o 'Math_udf'.

Look at RFUNC or FreeUDFLib. There are about 200 useful or useless
functions. Please, give people freedom what UDF library to choose.
Your point of view (from MySQL for example) is a bit tight.
Usually when server have lot of functions inside it, often
it is very complex to add new functions. Here, in InterBase/Firebird,
it's a piece of cake to get UDF dll, add it to server and register
in database. You can also create new udf in 2 minutes and add it
to server, and it will work without any performance loss.

--
Dmitri Kouzmenko