RE: Re[5]: [Firebird-devel] UDF library

[Claudio V. C. <cv...@us...>]

Dmitry Yemanov wrote:
>
> I meant that:
>
> 1) UDF has one parameter
> 2) this parameter is passed BY REFERENCE
> 3) UDF returns the result via this parameter (aka RETURNS PARAMETER 1)
> 4) UDF is called with NULL argument (in your case it will be a
> NULL pointer
> as a reference)
> 5) UDF should return non-null result for this case (e.g. numeric zero
> or empty string)
>
> AFAIU, in your scenario this UDF is not able to return _any_ data. Am
> I missing anything?

I can't get the idea. If the UDF uses RETURNS PARAMETER <n>, then it gets
- a null pointer for the input param that's NULL (using BY REFERENCE)
- a valid parameter to put the result. This is an extra parameter. The
engine builds it.
Therefore, there will be no conflict.

Now, you're referring to a more drastic case, when the only parameter is
indeed the return one. Then there's no input param. The engine will build
the only output param. It can't be null. (There's a bug that I'm trying to
solve now.)

Maybe you're thinking in this place:

	/* CVC: There's no other solution for now: timestamp can't be returned
	by value and the other way is to force the user to pass a dummy value as
	an argument to keep the engine happy. So, here's the hack. */
	case dtype_timestamp:
	    if (tail == return_ptr)
		{
			temp_ptr = value->vlu_desc.dsc_address;
			length = sizeof(GDS_TIMESTAMP);
		}
		else
		{
			MOV_move(input, &temp_desc);
		}
		break;

Honestly, the hack if no new thing. It's used in other data types like the
string family (char, varchar, cstring). Without it, getExactTimestamp()
can't work. In fact, it does work only in FB, because IB lacks this logic.

C.