If you are designing two or more similar data types, you should consider implementing your own data type hierarchy to avoid writing strategy and support functions for every possible combination of data type signatures.
This is part of the normal opaque user-defined data type creation. For more information about how to create these implicit casts, refer to IBM Informix: User-Defined Routines and Data Types Developer's Guide.
You do not need to create strategy functions for the subtypes because casts from the subtype to the supertype exist.
All of these SQL functions, however, can usually be mapped to the same C code; thus only one C function needs to be written.
If the query optimizer is unable to find a function for a particular subtype when it is executing a query, the query optimizer implicitly casts the subtype to the supertype and uses the function defined for the supertype.
The support or strategy function that is defined for the supertype must internally determine what actual data type it is operating on, and then it must execute the code that applies for that particular data type. This means that the internal C code for a function defined for the supertype also contains the C code that applies to all subtypes.
Assume you are designing three data types: MyPoint, MyBox, and MyCircle. Because they are all two-dimensional spatial data types, a supertype called MyShape could also be defined. This type hierarchy is described in Figure 4.
Using SQL, create casts between the three subtypes (MyPoint, MyBox, and MyCircle) and the supertype, MyShape.
The following two sections describe how to create the strategy and support functions.
When you create the strategy functions, such as Overlaps, only one function needs to be created in SQL: Overlaps (MyShape, MyShape). The internal C code for this Overlaps function first checks to see what actual data type it is operating on (either MyPoint, MyBox, or MyCircle), and then calls the appropriate code for that data type. For example, if the function call in the query was actually Overlaps (MyCircle, MyCircle), the appropriate code for the overlap between two MyCircle data types is executed.
If a query contains the expression Overlaps (MyCircle, MyCircle), the query optimizer first looks for a function with the same signature. It will not find one, because none has been defined. It does, however, find a cast from MyCircle to MyShape, so it searches for an Overlaps function that applies to the MyShape data type. Because this function does exist, the query optimizer executes it after implicitly casting MyCircle to MyShape.
By taking advantage of type hierarchies and casting, you avoid having to explicitly create the various combinations of Overlaps functions within SQL, such as Overlaps(MyPoint, MyPoint), Overlaps(MyBox, MyCircle), and so on.
The preceding discussion about type hierarchies and strategy functions is true for all strategy functions, not just for the Overlaps function.
When you create the Union support function, you must create separate SQL functions for each indexable column type. For example, you must create the following SQL Union functions:
Union (MyPoint, MyPoint, MyPoint) Union (MyBox, MyBox, MyBox) Union (MyCircle, MyCircle, MyCircle) Union (MyShape, MyShape, MyShape)
All these Union support functions, however, can be mapped to the same C code. Similar to strategy functions, the internal C code that the Union functions map to first checks to see what actual data type it is operating on (either MyPoint, MyBox, or MyCircle) and then calls the appropriate code for that data type. For example, if the function call is Union (MyCircle, MyCircle, MyCircle), it executes the appropriate code for the union of two MyCircle data types.
The preceding discussion is true only for the Union support function and not for the other support functions.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]