Extended Data Types

Home | Previous Page | Next Page Extending Data Types > Understanding Data Types >

Extended Data Types

The extensible data type system allows you to:

Define new data types, called extended data types, to extend the data type system
Define the behavior of extended data types:
- The operations that are supported on the extended data types
- New operator class that supports the extended data type and provides new functionality for a secondary-access method
- Additional casts to provide data conversions between the extended data types and other data types
- Functions that collect statistics for the optimizer

You can define the following extended data types:

Complex data types
- Collection types
- Row types
UDTs
- Opaque data types
- Distinct data types

The database server stores information about extended data types in the sysxtdtypes and sysxtdtypeauth system catalog tables. For information about these tables, refer to the IBM Informix: Guide to SQL Reference.

Complex Data Types

A complex data type is built from a combination of other data types. An SQL statement can access individual components within the complex type. The two kinds of complex types are as follows:

Collection types have instances that are groups of elements of the same data type, which can be any built-in or complex data type.
The requirements for elements with ordered position and uniqueness among the elements determine whether the collection is a SET, LIST, or MULTISET.
Row types have instances that are groups of related data fields, of any data type, that form a template for a record.
The assignment of a name to the row type determines whether the row type is a named row type or an unnamed row type.

Table 6 summarizes the complex data types that the database server supports.

Table 6. Complex Data Types of the Database Server
Data Type	Explanation
LIST(e)	Stores a collection of values that have an implicit position (first, second, and so on) and allows duplicate values All elements have the same element type, e.
MULTISET(e)	Stores a collection of values that have no implicit position and allows duplicate values All elements have the same element type, e.
Named row type	A row type created with the CREATE ROW TYPE statement This row type has a defined name and inheritance properties and can be used to construct a typed table. A named row type is not equivalent to another named row type, even if its field definitions are the same.
ROW (Unnamed row type)	A row type created with the SQL keyword ROW This row type has no defined name and no inheritance properties. Two unnamed row types are equivalent if they have the same number of fields and if corresponding fields have the same data type, even if the fields have different names.
SET(e)	Stores a collection of values that have no implicit position and does not allow duplicate values All elements have the same element type, e.

User-Defined Data Types

Table 7 summarizes the UDTs that the database server supports.

Table 7. User-Defined Data Types
Data Type	Explanation
Distinct	Has the same internal representation as the source data type on which it is based but has different casts and functions defined over it than those on the source type
Opaque	Fundamental data type that the user defines A fundamental data type is atomic; that is, it cannot be broken into smaller pieces, and it can serve as the building block for other data types.

American National Standards Institute

In an ANSI-compliant database, columns defined using user-defined types should be in the owner.object format.

End of American National Standards Institute

Distinct Data Type

A distinct type has the same internal structure as an existing data type. However, it has a distinct name and therefore distinct functions that make it different from its source type. When you define a distinct type, you provide the following information:

The source data type, which defines the internal structure of the distinct data type
The functions of the source data type determine how the database server interacts with this internal structure.
The operations that are valid on the distinct data type
You define operator functions, built-in functions, or end-user routines that handle the distinct type. For information about building operator functions, see Extending Operators and Built-In Functions.
Extensions of the operator class of a secondary-access method so that its strategy and support functions handle the distinct data type
For information about support functions, see Writing Support Functions.
Cast functions to provide the data conversions to and from the distinct type
The database server automatically creates explicit casts between the distinct type and its source type. Because these two data types have the same internal format, this cast does not require a cast function. You can write cast functions to support data conversion between the distinct type and other data types in the database or to support implicit casts between the distinct type and its source data type. For information about writing casts, see Creating User-Defined Casts.

You create a distinct data type with the CREATE DISTINCT TYPE statement. After you create the distinct type, you can use it anywhere that other data types are valid. For more information, refer to the description of this statement in the IBM Informix: Guide to SQL Syntax.

Opaque Data Type

Unlike other data types (built in, complex, and distinct), the internal structure of the opaque data type is not known to the database server. Therefore, when you define an opaque type, you must provide the following information:

The internal structure of the opaque data type, which provides the format of the data
You define the support functions of the opaque type to tell the database server how to interact with this internal structure.
The operations that are valid on the opaque data type
You define operator functions, built-in functions, or end-user routines that handle the opaque type.
Extensions of the operator class of a secondary-access method so that its strategy and support functions handle the opaque data type
Cast functions to provide the data conversions to and from the opaque type
The support functions of the opaque type also serve as cast functions.

You register an opaque data type with the CREATE OPAQUE TYPE statement. For information about this statement, refer to the IBM Informix: Guide to SQL Syntax. For more information, see Creating an Opaque Data Type, and Writing Support Functions.

IBM Informix DataBlade Modules

In addition to the extended data types that you explicitly define, you can use the pre-packaged extended data types that are provided. For example, an IBM Informix DataBlade module might contain the routines required to support a spherical coordinate system. For more information on IBM Informix DataBlade modules, consult your sales representative or refer to the user guides for the DataBlade modules.