TechTip: New Function Resolution Casting Rules for DB2

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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 invokedudf1 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 intuitivea 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.

 

Kent Milligan
Kent Milligan is a Senior Db2 for i Consultant in the IBM Lab Services Power Systems Delivery Practice.  Kent has over 25 years of experience as a Db2 for IBM i consultant and developer working out of the IBM Rochester lab. Prior to re-joining the DB2 for i Lab Services practice in 2020, Kent spent 5 years working on healthcare solutions powered by IBM Watson technologies. Kent is a sought-after speaker and author on Db2 for i & SQL topics.
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: