They may be obscure, but they're definitely not to be overlooked.

My recent article on the DB2 for i 7.2 release highlighted some of the more noteworthy database enhancements in the latest IBM i release. There wasn't room in the previous article to discuss all of the DB2 enhancements, so in this article you'll learn about a smaller DB2 improvement known as function resolution casting rules.

Function resolution is the process that DB2 must go through each time an SQL statement like the following example references a user-defined function (UDF). This example has two different UDFs being invoked—udf1 and udf2.

   SELECT udf1('ABC'), pgmlib.udf2(1,mycol) FROM mytable

Function resolution can be a complex process because the SQL standard allows overloading of functions. In the prior example, that means there could be multiple versions of the udf2 function in the library named pgmlib as long as the parameter signature of each function is unique.

While few IBM i developers create overloaded UDFs, many developers have been negatively impacted by the pre-7.2 function resolution rules defined by the SQL standard. The function resolution rule that has caused the most headaches is associated with the promotion of data types.

Essentially, the data type promotion rules define what data types are allowed to be passed to the parameters. For example, a decimal value cannot be passed for a function parameter defined as a character. That's pretty intuitive for most people, but the SQL standard had one promotion rule that isn't intuitive—a variable-length character value cannot be passed to a function parameter defined as the character data type. You can assign a variable-length character string to a fixed-length character column, but the standard doesn't allow you to pass a variable-length character string to a fixed-length character parameter!

This strange rule has resulted in many developers receiving a "Function not found" error from DB2. Let's use the definition for the udf1 function as an example. Notice in the definition that parm1 is defined as a fixed-length character.

CREATE FUNCTION udf1(parm1 CHAR(3))

RETURNS CHAR(4)

LANGUAGE SQL

BEGIN 

RETURN( CONCAT (parm1,'Z'));

END

With this function definition for udf1, the earlier SELECT statement will always fail with a "Function not found" error, even if the function name is explicitly qualified with a library name. This error occurs because SQL passes any character literal (e.g., 'ABC') as a variable-length character string. As you just learned, the pre-7.2 function resolution rules don't allow a variable-length character to be passed to a fixed-length character parameter.

The IBM i 7.2 release brings a remedy to this headache. My DB2 7.2 article highlights the new ability to define default values for function parameters. When the IBM DB2 product family designed this enhancement, the function resolution process was enhanced to also apply casting rules.

Casting rules define the allowable conversions between data types. As discussed earlier, SQL allows a variable-length character value to be assigned to a fixed-length character column. Thus, the application of casting rules during the function resolution process means that more "function not found" errors should disappear because variable-length character values can now be passed to fixed-length character parameters!

The DB2 product family is also working on getting this more-logical behavior added to the SQL standard definition for function resolution.

This explanation might provide more details than you need, but the point of this discussion is that the DB2 7.2 release contains another feature that makes UDFs easier to implement.

While we're on the subject of UDFs, don't forget my "oldie but goodie" tip on improving UDF performance on all release levels.