Declares a graphic character string literal in an expression.
Syntax
G '<ABC>'
- G
- The string is graphic data.
- '
- String delimiter for a graphic character string.
- <ABC>
- A string of valid KanjiEBCDIC multibyte characters surrounded by Shift-Out and Shift-In characters.
ANSI Compliance
Graphic literals are Teradata extensions to the ANSI SQL:2011 standard.
Rules
- On a Japanese character site, the G'string' syntax for graphic string literals can only be used when the KanjiEBCDIC character set is in effect for the session. It is equivalent to _Graphic 'string'.
- The _Graphic 'string' form can be used from any session character set, and is the recommended form for specifying literals required to be within the graphic repertoire.
- For other character sets, you can use the hexadecimal representation of the graphic string (see Hexadecimal Byte Literals).
- The literal must be enclosed within Shift-Out/Shift-In characters, as normal KanjiEBCDIC encoding requires.
- The maximum length is 15500 logical (double byte) characters.
Note that the Shift-Out/Shift-In characters are not included in the byte count and are not stored as part of the graphic literal.
- The contents must be valid graphic data (multibyte characters that are printable under the KanjiEBCDIC character set in effect for the current session).
- The internal representation must be an even number of bytes.
Case Specificity of Character String Literals
- SQL query text
- View and macro definition text
- CHECK constraint text
In all of these instances, execution of queries using these literals involves parsing the literals and assigning case specific attributes to them at that time.
| IF the session is in this mode … | THEN the default case specificity of character string literals is … |
|---|---|
| ANSI | CASESPECIFIC. |
| Teradata | NOT CASESPECIFIC. The exception is character data of type CHARACTER or VARCHAR CHARACTER SET GRAPHIC, which is always CASESPECIFIC. |
This means that for views with WHERE constraints and for CHECK, if character string literals are included, they compare differently when executed by users with sessions in ANSI and Teradata mode.
To override the default case specificity attribute, apply the CASESPECIFIC or NOT CASESPECIFIC phrase to the character string literal.
You should modify existing views having WHERE constraints to explicitly control case specificity for comparisons.
Note that the collation in effect for the session can also cause character string literals to compare differently.
Further Information
See “ALTER TABLE” and “CREATE TABLE” in Teradata Vantage™ - SQL Data Definition Language Syntax and Examples, B035-1144 for explanations on the use of CHECK.
Also see “Case Specificity” in Teradata Vantage™ - SQL Functions, Expressions, and Predicates, B035-1145.
You should explicitly control case specificity in character string comparisons. For information about how to explicitly control case specificity, see “CASESPECIFIC Phrase” and “UPPERCASE Phrase” in Character and CLOB Data Types of this volume.