> -----Original Message-----
> From: Ann W. Harrison [mailto:harrison@...]
> Sent: Viernes 1 de Diciembre de 2000 20:06
>
> The original design (for those who haven't been here since
> day 1) included three mechanisms for passing values between
> InterBase and a UDF: value, reference, and descriptor. The
> last actually passed a pointer to a structure that included
> the datatype, length, scale, null status, and a pointer to
> the actual data.

I've been staring at system tables for some time, trying to figure out how
to use this descriptor, but I don't know if there's more hidden treasures
than the formal and official UDF declaration other than the optional syntax
to declare a parameter to be the return value (and hence avoiding the
headaches with FREE_IT). Perhaps those values are only documented in system
tables or not available to DSQL.

> That mechanism allowed the very clever (ambitious? overly
> eager? utterly insane?)

This is a community of insane people, so any programming insanity is
potentially welcome.
:-)

> programmer to write UDF's that were
> data type independent. There has been no great clamor
> for datatype independence from the user base, but there
> is frequent complaint about the absence of null handling.

One of the claims is data independence, because it would allow you to
create UDFs like NULLIF without having to rely on one UDF name per data
type, for example.
Also, I've seen that some current UDFs assume that when they get a NULL
pointer instead of the data, this is a SQL NULL, when the parameter was
received as a pointer.
For those of you that didn't pay attention to IB_UDF (the "official UDF"),
it cannot signal NAN or other special states as stated in the source code.
This seems to be an issue only with math UDFs.
Finally, the fact that an UDF that attempts some invalid memory access and
it's caught by the server causes the server to terminate due to an internal
check, doesn't make my very happy, but perhaps there's no better way to
react.

C.