TERA Mode For Strings Comparison - NO COLLATE
This section defines the translation specification for string in Tera mode without using COLLATE.
Description
Tera Mode for string comparison and NO COLLATE usages
The Tera Mode string comparison without the use of COLLATE will apply RTRIM
and UPPER
as needed. The default case specification trim behavior may be taken into account.
Sample Source Patterns
Setup data
Comparison operation
Case 1: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
This example demonstrates the usage of a column set up as NOT CASESPECIFIC
as it is a first_name
column. Even when asking for the string 'GEorge',
the query execution will retrieve results in Teradata because the case specification is not considered.
To emulate this scenario in Snowflake, there are implemented two functions: RTRIM(UPPER(string_evaluation))
, UPPER
is required in this scenario because the string does not review the case specification.
Teradata
Snowflake
Case 2: Column constraint is CASESPECIFIC and database mode is TERA Mode
For this example, the column constraint is CASESPECIFIC
, for which the example does not retrieve rows in Teradata because 'Snow
' is not equal to 'SNOW
'.
In Snowflake, the resulting migration points only to the use of the RTRIM
function since the case specification is important.
Teradata
Snowflake
Case 3: CAST CASESPECIFIC column to NOT CASESPECIFIC and database mode is TERA Mode
Teradata
The (CASESPECIFIC
) overrides the column constraint in the table definition.
Snowflake
RTRIM is required on the left side, and RTRIM is required on the right side.
Case 4: CAST NOT CASESPECIFIC column to NOT CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Case 5: Blank spaces case. Column constraint is NOT CASESPECIFIC, database mode is TERA Mode, and using equal operation
Teradata
Snowflake
LIKE operation
This operation works differently from another one. Blank spaces must be the same quantity to retrieve information.
Case 1: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
This example is expected to display one row because the case specification is not relevant.
In Snowflake, the migration uses the ILIKE operation. This performs a case-insensitive comparison.
Teradata
Snowflake
Case 2: Column constraint is CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Case 3: CAST CASESPECIFIC column to NOT CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Case 4: CAST NOT CASESPECIFIC column to NOT CASESPECIFIC and database mode is ANSI Mode
This case requires the translation to ILIKE
.
Teradata
Snowflake
IN Operation
Case 1: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Case 2: Column constraint is CASESPECIFIC and database mode is TERA Mode
For this example, the usage of the UPPER function is not required since, in the Teradata database, the case specification is relevant to the results.
Teradata
Snowflake
ORDER BY clause
Case 1: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
Notice that this output order can differ.
Teradata
Snowflake
Case 2: Column constraint is CASESPECIFIC and database mode is TERA Mode
Notice that this output can differ in order.
Teradata
Snowflake
GROUP BY clause
Notice that this output can differ. To ensure a functional equivalence, it is required to use the COLLATE expression.
Please review the SSC-EWI-TD0007 for more information.
The following might be a workaround without collate
:
SELECT RTRIM(UPPER(first_name))
FROM employees
GROUP BY RTRIM(UPPER(first_name));
About the column behavior
Please review the insertion of data in Snowflake. Snowflake does allow the insertion of values as 'GEORGE
' and 'georges
' without showing errors because the case specification is not bound explicitly with the column.
Assume a table and data as follows:
Notice that this sample does not allow inserting values with upper and lower case letters in the NOT CASESPECIFIC
column because it takes it as the same value. Because the column does not supervise the case specification, the 'GEORGE' and 'george' values are checked as the same information.
The following rows are taken as duplicated row errors:
Case 1: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Case 2: Column constraint is CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
HAVING clause
The HAVING clause will use the patterns in:
Evaluation operations.
For example:
=, !=, <, >.
LIKE operation.
IN Operation.
CAST to evaluation operation.
CAST to LIKE operation.
The following sample showcases a pattern with evaluation operation.
Sample: Column constraint is CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
CASE WHEN statement
The CASE WHEN
statement will use the patterns described in:
Evaluation operations.
For example:
=, !=, <, >.
LIKE operation.
IN Operation.
CAST to evaluation operation.
CAST to LIKE operation.
The following sample showcases a pattern with evaluation operation.
Teradata
Snowflake
JOIN clause
Simple scenarios are supported.
The JOIN
statement will use the patterns described in:
Evaluation operations.
For example:
=, !=, <, >.
LIKE operation.
IN Operation.
CAST to evaluation operation.
CAST to LIKE operation.
The following sample showcases a pattern with evaluation operation.
Sample: Column constraint is NOT CASESPECIFIC and database mode is TERA Mode
Teradata
Snowflake
Known Issues
there are some mode-specific SQL statement restrictions:
BEGIN TRANSACTION
,END TRANSACTION
,COMMIT [WORK]
.Data insertion may differ in Snowflake since the case specification is not bound to the column declaration.
GROUP BY
may differ in order, but group the correct values.ORDER BY
behaves differently in Snowflake.If a function has a TRIM() from the source code, this workaround will add the required functions to the source code. So, RTRIM will be applied to the TRIM() source function.
Related EWIs
SSC-EWI-TD0007: GROUP BY IS NOT EQUIVALENT IN TERADATA MODE
Last updated