At 12:46 PM 4/2/01 -0000, you wrote:

>
>1. Declaring UDF's in every database on a server.
>I believe that having an ability to declare Server wide UDF's would be
>a big advantage. If this could be done, then an installation of
>Interbase or Firebird could include a number of verified UDF's which
>would greatly enhance the product. The problem at the moment as I see
>it is that the perception in the marketplace is that Interbase has a
>very poor number of functions complared to its rivals.
>

There are two issues. I think everyone agrees that a larger
(and better) library would be better. The question of administration
is quite different. The existing philosophy, admittedly long in
tooth, is that various groups or applications with no relationship
could share a machine, which mandated per database administration.
This question has been revisited a number of times. I have always
favored decentralization.

>2. Null values in fields/ Multitype UDF's.
>With the current implementation of UDF's the UDF writer cannot access
>a null parameter or indicate that a returned parameter is null. How
>difficult would it be to implement a new interbase type (as a struct
>or record) which could be passed to and from a UDF? Something
>containing the following information.
>

The exiting mechanism can pass internal descriptors (which have
all the crud you want), but it isn't particularly documented.
Read to code and write a HOWTO.

>
>3. Java UDF's
>Cross platform UDF creation for me is a pain. I know at present that
>the udf's I am writing are required on both linux and windows but I
>have no idea what other platforms I will have to provide the library
>on. Allowing udf's to be written in java would completetly alleviate
>this problem.
>

My favorite topic. Not a non-trivial undertaking. The strategic
question is whether to bless a single JVM or try to support the
full herd. In theory it shouldn't make a difference...

However, supporting UDFs in Java would require engine local JDBC
semantics, which is a mouthfull.



Jim Starkey