Release Notes

42.6 Data Type Information

42.6.1 Promotion of Data Types

In this section table 5 shows the precedence list for each data type. Please note:

For a Unicode database, the following are considered to be equivalent data types:
- CHAR and GRAPHIC
- VARCHAR and VARGRAPHIC
- LONG VARCHAR and LONG VARGRAPHIC
- CLOB and DBCLOB
In a Unicode database, it is possible to create functions where the only difference in the function signature is between equivalent CHAR and GRAPHIC data types, for example, foo(CHAR(8)) and foo(GRAPHIC(8)). We strongly recommend that you do not define such duplicate functions since migration to a future release will require one of them to be dropped before the migration will proceed.
If such duplicate functions do exist, the choice of which one to invoke is determined by a two-pass algorithm. The first pass attempts to find a match using the same algorithm as is used for resolving functions in a non-Unicode database. If no match is found, then a second pass will be done taking into account the following promotion precedence for CHAR and GRAPHIC strings:
```
GRAPHIC-->CHAR-->VARGRAPHIC-->VARCHAR-->LONG VARGRAPHIC-->LONG VARCHAR-->
     -->DBCLOB-->CLOB
```

42.6.2 Casting between Data Types

The following entry has been added to the list introduced as: "The following casts involving distinct types are supported":

For a Unicode database, cast from a VARCHAR or VARGRAPHIC to distinct type DT with a source data type CHAR or GRAPHIC.

The following are updates to "Table 6. Supported Casts between Built-in Data Types". Only the affected rows of the table are included.

Table 18. Supported Casts between Built-in Data Types

Target Data Type > Source Data Type V	C H A R	V A R C H A R	L O N G V A R C H A R	C L O B	G R A P H I C	V A R G R A P H I C	L O N G V A R G R A P H I C	D B C L O B
CHAR	Y	Y	Y	Y	Y¹	Y¹	-	-
VARCHAR	Y	Y	Y	Y	Y¹	Y¹	-	-
LONGVARCHAR	Y	Y	Y	Y	-	-	Y¹	Y¹
CLOB	Y	Y	Y	Y	-	-	-	Y¹
GRAPHIC	Y¹	Y¹	-	-	Y	Y	Y	Y
VARGRAPHIC	Y¹	Y¹	-	-	Y	Y	Y	Y
LONGVARGRAPHIC	-	-	Y¹	Y¹	Y	Y	Y	Y
DBCLOB	-	-	-	Y¹	Y	Y	Y	Y

¹: Cast is only supported for Unicode databases.

42.6.3 Assignments and Comparisons

Assignments and comparisons involving both character and graphic data are only supported when one of the strings is a literal. For function resolution, graphic literals and character literals will both match character and graphic function parameters.

The following are updates to "Table 7. Data Type Compatibility for Assignments and Comparisons". Only the affected rows of the table, and the new footnote 6, are included:

Operands	Binary Integer	Decimal Number	Floating Point	Character String	Graphic String	Date	Time	Time- stamp	Binary String	UDT
Character String	No	No	No	Yes	Yes ⁶	¹	¹	¹	No ³	²
Graphic String	No	No	No	Yes ⁶	Yes	No	No	No	No	²

⁶: Only supported for Unicode databases.

42.6.3.1 String Assignments

Storage Assignment

The last paragraph of this subsectoin is modified as follows:

When a string is assigned to a fixed-length column and the length of the string is less than the length attribute of the target, the string is padded to the right with the necessary number of single-byte, double-byte, or UCS-2² blanks. The pad character is always a blank even for columns defined with the FOR BIT DATA attribute.

Retrieval Assignment

The third paragraph of this subsectoin is modified as follows:

When a character string is assigned to a fixed-length variable and the length of the string is less than the length attribute of the target, the string is padded to the right with the necessary number of single-byte, double-byte, or UCS-2² blanks. The pad character is always a blank even for strings defined with the FOR BIT DATA attribute.

²: UCS-2 defines several SPACE characters with different properties. For a Unicode database, the database manager always uses the ASCII SPACE at position x'0020' as UCS-2 blank. For an EUC database, the IDEOGRAPHIC SPACE at position x'3000' is used for padding GRAPHIC strings.

Conversion Rules for String Assignments

The following paragraph has been added to the end of this subsectoin:

For Unicode databases, character strings can be assigned to a graphic column, and graphic strings can be assigned to a character column.

DBCS Considerations for Graphic String Assignments

The first paragraph of this subsectoin has been modified as follows:

Graphic string assignments are processed in a manner analogous to that for character strings. For non-Unicode databases, graphic string data types are compatible only with other graphic string data types, and never with numeric, character string, or datetime data types. For Unicode databases, graphic string data types are compatible with character string data types.

42.6.3.2 String Comparisons

Conversion Rules for Comparison

This subsection has been modified as follows:

When two strings are compared, one of the strings is first converted, if necessary, to the encoding scheme and code page of the other string. For details, see the "Rules for String Conversions" section of "Chapter 3. Language Elements" in the SQL Reference.

42.6.4 Rules for Result Data Types

42.6.4.1 Character and Graphic Strings in a Unicode Database

This is a new subsection inserted after the subsection "Graphic Strings".

In a Unicode database, character strings and graphic strings are compatible.

If one operand is...	And the other operand is...	The data type of the result is...
GRAPHIC(x)	CHAR(y) or GRAPHIC(y)	GRAPHIC(z) where z = max(x,y)
VARGRAPHIC(x)	CHAR(y) or VARCHAR(y)	VARGRAPHIC(z) where z = max(x,y)
VARCHAR(x)	GRAPHIC(y) or VARGRAPHIC	VARGRAPHIC(z) where z = max(x,y)
LONG VARGRAPHIC	CHAR(y) or VARCHAR(y) or LONG VARCHAR	LONG VARGRAPHIC
LONG VARCHAR	GRAPHIC(y) or VARGRAPHIC(y)	LONG VARGRAPHIC
DBCLOB(x)	CHAR(y) or VARCHAR(y) or CLOB(y)	DBCLOB(z) where z = max(x,y)
DBCLOB(x)	LONG VARCHAR	DBCLOB(z) where z = max(x,16350)
CLOB(x)	GRAPHIC(y) or VARGRAPHIC(y)	DBCLOB(z) where z = max(x,y)
CLOB(x)	LONG VARGRAPHIC	DBCLOB(z) where z = max(x,16350)

42.6.5 Rules for String Conversions

The third point has been added to the following list in this section:

For each pair of code pages, the result is determined by the sequential application of the following rules:

If the code pages are equal, the result is that code page.
If either code page is BIT DATA (code page 0), the result code page is BIT DATA.
In a Unicode database, if one code page denotes data in an encoding scheme different from the other code page, the result is UCS-2 over UTF-8 (that is, the graphic data type over the character data type).¹
Otherwise, the result code page is determined by Table 8 of the "Rules for String Conversions" section of "Chapter 3. Language Elements" in the SQL Reference. An entry of "first" in the table means the code page from the first operand is selected and an entry of "second" means the code page from the second operand is selected.

¹: In a non-Unicode database, conversion between different encoding schemes is not supported.

42.6.6 Expressions

The following has been added:

In a Unicode database, an expression that accepts a character or graphic string will accept any string types for which conversion is supported.

42.6.6.1 With the Concatenation Operator

The following has been added to the end of this subsection:

In a Unicode database, concatenation involving both character string operands and graphic string operands will first convert the character operands to graphic operands. Note that in a non-Unicode database, concatenation cannot involve both character and graphic operands.

42.6.7 Predicates

The following entry has been added to the list introduced by the sentence: "The following rules apply to all types of predicates":

In a Unicode database, all predicates that accept a character or graphic string will accept any string types for which conversion is supported.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]