|Subject||RE: [IB-Architect] UDF and null|
|Author||Claudio Valderrama C.|
> -----Original Message-----I've been staring at system tables for some time, trying to figure out how
> 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.
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? overlyThis is a community of insane people, so any programming insanity is
> eager? utterly insane?)
> programmer to write UDF's that wereOne of the claims is data independence, because it would allow you to
> 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.
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