Extending INFORMIX-Universal Server: User-Defined Routines

Extending INFORMIX-Universal Server: User-Defined Routines
Chapter 3: Designing a User-Defined Routine

Home Contents Index Master Index New Book

Designing the Routine Source

When you design a user-defined routine, you must consider the following:

Naming your routine
Number of arguments
Coding standards

Naming Your Routine

Choose sensible names for your routines. The routine name should be easy to remember and succinctly describe what the routine does. Because Universal Server supports polymorphism, you can have multiple routines with the same name that take different arguments. This is contrary to programming practice in some high-level languages. For example, a C programmer might be tempted to create functions with the following names that return the larger of their arguments:

	bigger_int(integer, integer)
	bigger_real(real, real)

In SQL, these routines are better defined in the following way:

	bigger(integer, integer)
	bigger(real, real)

Using the naming in the second example allows users to ignore the types of the arguments when they call the routine. They simply remember what it does and let Universal Server choose which supporting routine to call based on the argument types. This makes the user-defined routine simpler to use.

Routine overloading refers to the ability to assign one name to multiple routines and specify different types of arguments on which the routines can operate. For more information on routine determination, refer to "The Routine-Resolution Process".

You should consider the following questions about routine naming and design:

Are any of my routines modal?
Can I describe what each type and routine does in two sentences?
Do any of my routines take more than three arguments?
Have I used polymorphism effectively?

Number of Arguments

User-defined routines should take a small number of arguments and should not include arguments that make them modal. For example, the following statements show alternative routine calls to compute containment of spatial values:

Containment(polygon, polygon, integer);

Contains(polygon, polygon) 
ContainedBy(polygon, polygon)

The first example determines whether the first polygon contains the second polygon or whether the second contains the first. The caller supplies an integer argument (for example, one or zero) to identify which value to compute. This is modal behavior; the mode of the routine changes depending on the third argument.

The second example is better in that the routine names clearly explain what computation is performed. Always construct your routines to be nonmodal, as in the second example.

Coding Standards

The SQL/PSM standard is available for UDR development. In addition, Informix publishes a collection of standards for DataBlade module development. These standards are available from the DataBlade Developers Program. The most important rules govern the naming of data types and routines. DataBlade modules share these name spaces, so you must follow the naming guidelines to guarantee that no problems occur when you register multiple DataBlade modules in a single database.

In addition, the standards for 64-bit clean implementation, safe function-calling practices, thread-safe development, and platform portability are important. Adherence to these standards ensures that UDR modules are portable across platforms.

You should ask the following questions:

Do I obey all naming standards?
Is my design 64-bit safe and portable across platforms?
Is my design thread-safe?

Extending INFORMIX-Universal Server: User-Defined Routines, version 9.1
Copyright © 1998, Informix Software, Inc. All rights reserved.