Issue Details (XML | Word | Printable)

Key: CORE-690
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Pavel Cisar
Votes: 2
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

udf's adaptive return type

Created: 17/Sep/03 12:00 AM   Updated: 14/Jun/06 09:41 AM
Component/s: UDF
Affects Version/s: None
Fix Version/s: None

SF_ID: 807992


 Description  « Hide
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;

               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?

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:41 AM
Date: 2003-09-20 11:34
Sender: fpolizo
Logged In: YES
user_id=481626

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.