You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be really useful and not a nuisance as they are
now, some descriptor based udfs (like *nvl) should be
able to report a compatible data type and the engine
should check and accept the conversion if possible or
otherwise complain. Example:
invl takes two integers. It should be used with
integers. There's another int64nvl that works with
int64 quantities and returns int64. If the user misses
the right input parameter type, trash is returned:
SQL> select i64nvl(1,1) from rdb$database;
I64NVL
=====================
2012179293274113
It happens because the engine assumes the return
descriptor costains a pointer to an int64 and doesn't
check the returned descriptor and in this case, the
values passed are integers. Hence, a developer
currently should check the precision of a numeric
argument or do explicit casts to avoid those traps.
Ideally, the engine should inspect the return
descriptor and see if it can be converted to the
declared UDF's return type, otherwise raise an
exception. In this case, an int can be safely
converted to a greater type, int64.
Also, the current behavior that may result from mixing
a return value by descriptor and FREE_IT is undefined.
What should the engine deallocate, the value, the DSC
or both?
The text was updated successfully, but these errors were encountered:
You might consider adding support for UDF (and SP) "function
overloading" to help resolve this issue. This would allow
an app. developer to create specialized versions of a named
function for different input/output types. Oracle supports
this capability and it can be very useful.
Using the above example, all the *nvl () UDF names would be
replaced by a common name, say nvl(). Then a caller would
use the common name nvl() regardless of parameter types. The
engine would choose the correct function variant, based on
input/output parameters specified by the caller. If you
still want to, implicit type conversions could be performed
as needed to reduce the number of variants requred.
Exceptions would be raised when a compatible function
variant is not found matching the caller specified parameter
types.
Submitted by: @pcisar
Votes: 2
SFID: 807992#
Submitted By: pcisar
To be really useful and not a nuisance as they are
now, some descriptor based udfs (like *nvl) should be
able to report a compatible data type and the engine
should check and accept the conversion if possible or
otherwise complain. Example:
invl takes two integers. It should be used with
integers. There's another int64nvl that works with
int64 quantities and returns int64. If the user misses
the right input parameter type, trash is returned:
SQL> select i64nvl(1,1) from rdb$database;
=====================
2012179293274113
It happens because the engine assumes the return
descriptor costains a pointer to an int64 and doesn't
check the returned descriptor and in this case, the
values passed are integers. Hence, a developer
currently should check the precision of a numeric
argument or do explicit casts to avoid those traps.
Ideally, the engine should inspect the return
descriptor and see if it can be converted to the
declared UDF's return type, otherwise raise an
exception. In this case, an int can be safely
converted to a greater type, int64.
Also, the current behavior that may result from mixing
a return value by descriptor and FREE_IT is undefined.
What should the engine deallocate, the value, the DSC
or both?
The text was updated successfully, but these errors were encountered: