AWS Security ChangesHomeSearch

AWS dms documentation change

Service: dms · 2025-06-13 · Documentation low

File: dms/latest/userguide/schema-conversion-sql-server-postgresql.md

Summary

Added documentation for converting unsupported built-in objects to stub objects and new CITEXT datatype usage for case-insensitive string operations in PostgreSQL migrations

Security assessment

The changes document migration best practices and data type handling to maintain consistent case sensitivity behavior. While this relates to data integrity, there's no evidence of addressing a specific security vulnerability. The CITEXT guidance helps prevent potential data mismatches but isn't a direct security fix.

Diff

diff --git a/dms/latest/userguide/schema-conversion-sql-server-postgresql.md b/dms/latest/userguide/schema-conversion-sql-server-postgresql.md
index 8d4c3a7e6..5106977bf 100644
--- a//dms/latest/userguide/schema-conversion-sql-server-postgresql.md
+++ b//dms/latest/userguide/schema-conversion-sql-server-postgresql.md
@@ -30,0 +31 @@ SQL Server to PostgreSQL conversion settings in DMS Schema Conversion include th
+  * To convert unsupported built-in objects to stub objects, enable the **Convert unsupported built-in objects to stub objects** setting:
@@ -32,3 +33 @@ SQL Server to PostgreSQL conversion settings in DMS Schema Conversion include th
-
-
-To convert unsupported built-in objects to stub objects, enable the **Convert unsupported built-in objects to stub objects** setting. When enabled, DMS SC replaces unsupported built-in objects with corresponding stub objects in the target database. This feature converts code sections that would normally be enclosed by migration issue 7811 or 7904. It creates stub objects based on the type of the source built-in objects `PROCEDURE` for procedures, `VIEW` for views or tables.
+    * When enabled, DMS SC replaces unsupported built-in objects with corresponding stub objects in the target database. This feature converts code sections that would normally be enclosed by migration issue 7811 or 7904. It creates stub objects based on the type of the source built-in objects `PROCEDURE` for procedures, `VIEW` for views or tables.
@@ -40 +39 @@ You can choose to create stub objects in a separate schema by enabling the **Cre
-Stub routines are named based on the fully qualified name of the original built-in. For stub views, the naming convention includes the system schema name `system_schema_name$builtin_view_name`. 
+    * Stub routines are named based on the fully qualified name of the original built-in. For stub views, the naming convention includes the system schema name `system_schema_name$builtin_view_name`. 
@@ -45,0 +45,27 @@ After conversion, review and implement custom code for stub routines as needed.
+  * `CITEXT` datatype for all string datatypes setting in DMS Schema Conversion include the following:
+
+    * To use the `CITEXT` datatype for case-insensitive string operations when converting from SQL Server to PostgreSQL, enable the **Use CITEXT for all string datatypes** setting. This option helps maintain consistent behavior when migrating from a case-insensitive SQL Server to a case-sensitive PostgreSQL environment.
+
+    * When enabled, DMS SC converts all relevant string datatypes from the source SQL Server database to `CITEXT` in PostgreSQL. This eliminates the need for explicit LOWER () function calls in conditions and automatically casts string expressions in conditional operations to `CITEXT`.
+
+    * To determine if your SQL Server instance is case-sensitive, run the following query:
+        
+                SELECT SERVERPROPERTY('COLLATION');
+
+A result containing 'CI' indicates case-insensitive, while 'CS' indicates case-sensitive.
+
+    * The `CITEXT` conversion may not apply in scenarios where explicit case-sensitive collate settings are used at the server, database, or column level.
+
+To use this feature, ensure that the `CITEXT` module is installed and available in your target PostgreSQL database.
+
+    * When using the `CITEXT` datatype conversion, consider the following best practices:
+
+      * Enable this feature when migrating from a case-insensitive SQL Server to maintain consistent behavior in PostgreSQL.
+
+      * Review your application code to ensure it doesn't rely on case-sensitive string operations.
+
+      * Thoroughly test your application after migration to verify that case-insensitive behavior is maintained as expected.
+
+
+
+