Oracle -> RDS for PostgreSQL

long_support

LONG data type

It is applicable if tables contain one or more LONG columns. In Oracle, the maximum size of LONG data type is 2 GB. In PostgreSQL, the maximum size of TEXT data type is 1 GB.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert LONG data type. (Default value)

PostgreSQL does not support LONG data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert LONG to TEXT.

In Oracle, the maximum size of LONG data type is 2 GB, but in PostgreSQL, the maximum size of TEXT data type is 1 GB. There is no equivalent for LONG data type in PostgreSQL. If the table column data is beyond the limit, the data change operations (INSERT/UPDATE) fail and an error is thrown.

longraw_support

LONG RAW data type

It is applicable if tables contain one or more LONG RAW columns. In Oracle, the maximum size of LONG RAW data type is 2 GB. In PostgreSQL, the maximum size of BYTEA data type is 1 GB.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert LONG RAW type. (Default value)

PostgreSQL does not support LONG RAW data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

BYTEA

Convert LONG RAW to BYTEA.

In Oracle, the maximum size of LONG RAW data type is 2 GB, but in PostgreSQL, the maximum size of BYTEA data type is 1 GB. There is no equivalent for LONG RAW data type in PostgreSQL. If the table column data is beyond the limit, the data change operations (INSERT/UPDATE) fail and an error is thrown.

clob_support

CLOB data type

It is applicable if tables contain one or more CLOB columns. In Oracle, the maximum size of CLOB data type is 4 GB. In PostgreSQL, the maximum size of TEXT data type is 1 GB.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert CLOB data type.

In Oracle, the maximum size of CLOB data type is 4 GB. PostgreSQL does not support CLOB data type. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert CLOB data type to TEXT.

In PostgreSQL, the maximum size of TEXT data type is 1 GB. If the table column data is beyond the limit, the data change operations (INSERT/UPDATE) fail and an error is thrown.

nclob_support

NCLOB data type

It is applicable if tables contain one or more NCLOB columns. In Oracle, the maximum size of NCLOB data type is 4 GB. In PostgreSQL, the maximum size of TEXT data type is 1 GB.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert NCLOB. (Default value)

PostgreSQL does not support NCLOB data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert NCLOB data type to TEXT.

In Oracle, the maximum size of NCLOB data type is 4 GB. In PostgreSQL, the maximum size of TEXT data type is 1 GB. If the table column data is beyond the limit, the data change operations (INSERT/UPDATE) fail and an error is thrown.

blob_support

BLOB data type

It is applicable if tables contain one or more BLOB columns. In Oracle, the maximum size of BLOB data type is 4 GB. In PostgreSQL, the maximum size of BYTEA data type is 1 GB.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert BLOB data type. (Default value)

In Oracle, the maximum size of BLOB data type is 4 GB. PostgreSQL does not support BLOB data type. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

BYTEA

Convert BLOB data type to BYTEA.

In PostgreSQL, the maximum size of BYTEA data type is 1 GB. If the table column data is beyond the limit, the data change operations (INSERT/UPDATE) fail and an error is thrown.

float_support

FLOAT data type

It is applicable if tables contain one or more FLOAT columns and FLOAT is specified as FLOAT/FLOAT(n), where n > 53. If n is not provided, the default value 126 is used.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert FLOAT data type. (Default value)

PostgreSQL supports FLOAT data type, which is implicitly converted to DOUBLE PRECISION. In Oracle, the default precision (maximum precision) of FLOAT is 126. In PostgreSQL, if the FLOAT precision is greater than 53, an error will occur and the statement execution will fail.

NUMERIC

Convert FLOAT/FLOAT(n) data type to NUMERIC.

In PostgreSQL, if no precision is specified for NUMERIC data type, the maximum number of digits before the decimal point is 131072, and the maximum number of digits after the decimal point is 16383. The stored values are more accurate.

DOUBLE PRECISION

Convert FLOAT/FLOAT(n) data type to DOUBLE PRECISION.

DOUBLE PRECISION ranges from 1E-307 to 1E+308. The stored values may be approximately different. If there is a decimal part and the decimal digits are greater than 15, the remaining digits after the decimal point are rounded off.

number_with_zero_scale

NUMBER data type with zero scale

It is applicable if tables contain NUMBER with zero scale or NUMBER without scale.

Table, function, stored procedure, trigger, and user-defined type

0

Convert NUMBER to NUMERIC. (Default value)

PostgreSQL supports NUMERIC. The migration precision is exact.

1

If the precision of NUMBER is between 1 and 4, it is converted to SMALLINT type.

If the precision of NUMBER is between 5 and 9, it is converted to INT type.

If the precision of NUMBER is between 10 and 18, it is converted to BIGINT type.

If the input script is whole numbers, INTEGER is a better option to improve performance, but its migration precision is not exact.

SDO_GEOMETRY

SDO_GEOMETRY object type

It is applicable if tables contain SDO_GEOMETRY object type. There is no equivalent for SDO_GEOMETRY in PostgreSQL.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert SDO_GEOMETRY object type. (Default value)

PostgreSQL does not support SDO_GEOMETRY data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert SDO_GEOMETRY object type to TEXT.

Equivalent for SDO_GEOMETRY is not available in PostgreSQL. The DML statements should be corrected to store the TEXT data and to fetch the data into different object attributes.

MBRCOORDLIST

MDSYS.MBRCOORDLIST object type

It is applicable if the table script contains MBRCOORDLIST object type. There is no equivalent for MBRCOORDLIST in PostgreSQL.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert MBRCOORDLIST object type. (Default value)

PostgreSQL does not support MBRCOORDLIST data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert MBRCOORDLIST to TEXT.

There is no equivalent for MBRCOORDLIST in PostgreSQL. The DML statements should be corrected to store the TEXT data and to fetch the data into different object attributes.

GEOMETRY

GEOMETRY object type

It is applicable if the table script contains GEOMETRY object type. There is no equivalent for GEOMETRY in PostgreSQL.

Table, function, stored procedure, trigger, and user-defined type

IGNORE

Do not convert GEOMETRY object type. (Default value)

PostgreSQL does not support GEOMETRY data type. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

TEXT

Convert GEOMETRY to TEXT.

There is no equivalent for GEOMETRY in PostgreSQL. The DML statements should be corrected to store the TEXT data and to fetch the data into different object attributes.

partition_columns_with_unique_constraint

Unique constraints for table column partition

It is applicable if table scripts contain the partition syntax and primary keys or unique keys.

Table, index

0

Ignore the migration. (Default value)

This configuration ignores the migration. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

1

Comment the partition syntax.

Partitions can provide many benefits to applications by improving performance, manageability, and availability. After the partition syntax is commented, tables will become normal tables (not partitioned tables) and you will miss out the partition benefits specified above.

2

Comment unique constraints (primary keys and unique keys).

Unique constraints help:

• Avoid creating duplicate records in a table
• Create referential integrity constraints
• Accelerate database operations such as searching for records because indexes are created based on unique keys.

After the unique constraints (primary keys and unique keys) are commented, you will miss out the benefits specified above.

3

Add partition keys to the unique constraints (primary keys and unique keys).

After partition columns are added to the unique constraints (primary keys and unique keys), duplicate records may be created in the table.

mig_interval_partition

Interval partition in tables

It is applicable if table scripts contain interval partition syntax.

Table

IGNORE

Do not convert the INTERVAL partition syntax. (Default value)

PostgreSQL does not support the INTERVAL partition syntax. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

COMMENT

Comment the INTERVAL partition syntax.

After the INTERVAL partition syntax is commented, you will miss out the partition benefits in performance, manageability and availability.

on_null_support

DEFAULT ON NULL clauses

It is applicable if the input table scripts contain DEFAULT ON NULL clauses. A DEFAULT ON NULL clause will configure DEFAULT for a column even when a null value has been explicitly included in the INSERT statement. There is no equivalent for DEFAULT ON NULL in PostgreSQL.

Table

IGNORE

Do not convert the DEFAULT ON NULL keyword. (Default value)

PostgreSQL does not support DEFAULT ON NULL clause. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

COMMENT

Comment the DEFAULT ON NULL keyword.

DEFAULT ON NULL does not support the DEFAULT ON NULL clause in PostgreSQL. It will be commented. If NULL is provided explicitly, the DML statements should be changed to store appropriate values.

generated_identity_support

IDENTITY columns

It is applicable if input table scripts contain IDENTITY columns using GENERATED AS IDENTITY.

Table, index

IGNORE

Do not convert IDENTITY columns. (Default value)

PostgreSQL does not support the GNERATED AS IDENTITY syntax. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

SERIAL

Convert IDENTITY columns to SERIAL columns.

SERIAL data type is four-byte auto-incrementing integer. Its range is 1 to 2,147,483,647. If the upper limit or lower limit is exceeded, an error will be reported and DML statements fail to be executed.

SMALL SERIAL

Convert IDENTITY columns to small SERIAL columns.

Small SERIAL data type is two-byte auto-incrementing integer. Its range is 1 to 32,767. If the upper limit or lower limit is exceeded, an error will be reported and DML statements fail to be executed.

BIG SERIAL

Convert IDENTITY columns to big SERIAL columns.

Big SERIAL data type is eight-byte auto-incrementing integer. Its range is 1 to 9,223,372,036,854,775,807. If the upper limit or lower limit is exceeded, an error will be reported and DML statements fail to be executed.

DEFAULT_SEQ

Create a sequence and use it as the default value.

The maximum and minimum values are 2⁶³-1 and -2⁶³-1. If the upper limit or lower limit is exceeded, an error will be reported and DML statements fail to be executed.

read_only_table

Read-only keyword in tables

It is applicable if the input table scripts contain read only keyword. In Oracle, tables are marked as read only using the ALTER TABLE command. When a table is in read-only mode, operations that attempt to modify table data are not allowed.

Table

IGNORE

Do not convert the READ ONLY keyword

PostgreSQL does not support the READ ONLY keyword. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

COMMENT

Comment the READ ONLY keyword in ALTER TABLE statements. (Default value)

PostgreSQL does not support the READ ONLY keyword. It will be commented. The keyword is generally not used in application scripts, but is used in database maintenance. It can be handled by creating a trigger.

TRIGGER

Create a trigger to support the READ ONLY mode.

If the parameter value is TRIGGER, a trigger can be created in READ ONLY mode.

global_temp_table_support

Global temporary tables

It is applicable if the input table scripts contain GLOBAL TEMPORARY keyword. A global temporary table is a permanent database object. Its table structure will be retained in the database even after the session is disconnected. A local temporary table is scoped to the session in which you created it. Its table is deleted once the session disconnects. PostgreSQL supports only local temporary tables.

Table

0

Do not convert the GLOBAL keyword. (Default value)

A local temporary table will be created by PostgreSQL regardless of whether a global or local table is specified. If no temporary table exists, create it manually.

1

Create a local temporary table.

A global temporary table will be converted to a local temporary table. If no temporary table exists, create it manually.

bitmap_index

BITMAP index

It is applicable if CREATE INDEX statements contains BITMAP keyword.

Index

0

No conversion will be happened. BITMAP keyword will be retained as it is. (Default value)

PostgreSQL does not support BITMAP indexes. The indexes are not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

1

Comment BITMAP indexes.

PostgreSQL does not support BITMAP indexes. The indexes will be commented. When indexed columns are used in search criteria, performance problems may occur. Therefore, you should create proper indexes.

2

Create BTREE indexes instead of BITMAP indexes.

BITMAP indexes are typically used for columns with a large number of duplicate values (low cardinality), while BTREE indexes are suitable for high cardinality columns. There is no exact equivalent for BITMAP indexes in PostgreSQL. You can create BTREE indexes.

3

Create HASH indexes instead of BITMAP indexes.

There is no exact equivalent for BITMAP indexes in PostgreSQL. The HASH index can be considered if an indexed column is used only when = operator is used for comparison.

reverse_support

REVERSE keyword in CREATE INDEX statements

It is applicable if CREATE INDEX statements contain REVERSE keyword.

Index

IGNORE

Do not convert the REVERSE keyword. (Default value)

PostgreSQL does not support REVERSE indexes. The indexes will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

COMMENT

Comment the REVERSE keyword.

PostgreSQL does not support REVERSE indexes. The keyword will be commented. REVERSE indexes will be converted to common indexes supported by PostgreSQL. There is no exact equivalent for REVERSE indexes for PostgreSQL. You can use B-tree indexes.

viewEditioning

EDITIONING views

It is applicable if the input view scripts contain EDITIONING keyword. In Oracle, it is allowed to create DML triggers on EDITIONING views.

View

0

Do not convert the EDITIONING keyword. (Default value)

PostgreSQL does not support the EDITIONING keyword. It will not be converted. Compiling the migrated scripts on PostgreSQL will fail. You should manually correct it. If a DML trigger is created in views, the trigger should be rewritten in the base table without affecting the business logic.

1

Comment EDITIONING keyword in view statements

PostgreSQL does not support the EDITIONING keyword. It will be commented. If a DML trigger is created in views, the trigger should be rewritten in the base table without affecting the business logic.

seq_max_min_value

Sequence value beyond the limit

It is applicable if the sequence scripts contain MAXVALUE and MINVALUE. Their values are beyond the limits supported by PostgreSQL.

Table, sequence

0

Do not change the value of MINVALUE or MAXVALUE even if its value exceeds the lower or upper limit (9223372036854775808 or 9223372036854775807). (Default value)

Oracle supports MAXVALUE and MINVALUE up to 10²⁷ and -10²⁶ respectively. If the input MINVALUE/MAXVALUE of a sequence goes beyond the limit (-9223372036854775808 or 9223372036854775807), compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

1

If the input MINVALUE/MAXVALUE of a sequence goes beyond the limit (-9223372036854775808 or 9223372036854775807), use the boundary value.

If the input MINVALUE/MAXVALUE of a sequence goes beyond the limit (-9223372036854775808 or 9223372036854775807), the boundary value is used. The generated sequence value does not exceed the upper and lower limits of PostgreSQL.

otherthan_gregorian

Calendar types other than GREGORIAN

It is applicable if the input TO_DATE function contains calendar type other than GREGORIAN.

Table

0

If the third parameter is specified in TO_DATE and TO_TIMESTAMP, do not comment GREGORIAN calendar. (Default value)

PostgreSQL supports only the GREGORIAN calendar and the TO_DATE and TO_TIMESTAMP parameters. If other than GREGORIAN calendar is specified as a third parameter in Oracle TO_DATE function, GREGORIAN calendar will not be commented, but compiling the migrated scripts on PostgreSQL will fail. You should manually correct it.

1

If the third parameter is specified in TO_DATE and TO_TIMESTAMP, comment GREGORIAN calendar.

If other than GREGORIAN calendar is specified as a third parameter in Oracle TO_DATE function, GREGORIAN calendar will be commented. Compiling the migrated scripts on PostgreSQL will success.

object_name_combiner

Setting Object name combiners

It is applicable if the CREATE INDEX scripts contain schema names or the CREATE TABLE scripts contain partition syntax.

Table, index

$

Merge:

- Schema names and index names in CREATED INDEX statements

- Table names and partition names in CREATE PARTITIONED TABLE statements

Sample delimiters are: $#_

A delimiter string can contain a maximum of four characters. DOT(.) and any other special characters are not allowed for object_name_combiner.

default_schema

Setting default schema names

It is applicable if schema names are not provided in creating database objects.

schema

-

The default schema name is used for a database object whose schema name is not specified.

The default schema name is used and the schema name cannot be empty.

plsql_delimiter

Setting PL/SQL delimiter

It is applicable when the scripts contain PL/SQL object blocks (in stored procedures, functions, and packages).

Function, stored procedure, and trigger

$$

$$ is the default PL/SQL delimiter. You can change it.

Thanks to delimiters, stored procedures, functions and triggers are executed as a single unit. Therefore, delimiters cannot be used in any PL/SQL scripts (procedures, functions, or triggers).

package_name_delimiter

Setting package name delimiters

It is applicable if the input scripts contain CREATE PACKAGE statements.

Function, stored procedure, and trigger

$

Set a delimiter to form the name of a sub-object of a package during the Oracle package migration.

Delimiters are used for package conversion. For example, if the dollar sign ($) is used as a delimiter, the name of the specified stored procedure or function in a package will be converted to packageName$procedureName or packageName$functionName.

Sample delimiters are: $#_

A delimiter string can contain a maximum of four characters. DOT(.) and any other special characters cannot be used as the delimiters.

comment_commit

COMMIT/ROLLBACK keyword

It is applicable if procedures or functions contain the COMMIT/ROLLBACK statements. According to PostgreSQL documentation, stored procedures and functions support COMMIT and ROLLBACK statements.

Stored procedure

FALSE

Do not convert COMMIT/ROLLBACK statements. (Default value)

According to PostgreSQL documentation, stored procedures and functions support COMMIT and ROLLBACK statements. However, in some PostgreSQL versions (earlier versions), stored procedures and functions do not support COMMIT & ROLLBACK. As a result, the stored procedures and functions fail to be executed. You should manually correct the error.

TRUE

Comment the COMMIT/ROLLBACK statements.

According to PostgreSQL documentation, stored procedures and functions support COMMIT and ROLLBACK statements. However, in some (earlier) versions of PostgreSQL, stored procedures and functions do not support COMMIT and ROLLBACK. COMMIT and ROLLBACK will be commented. You need to correct the PL/SQL code to ensure that the service logic, especially the rollback logic, is not affected.

comment_tablespace

Tablespace

It is applicable if CREATE TABLE and CREATE INDEX statements contain TABLESPACE clauses.

Tablespace, table

FALSE

Do not convert TABLESPACE. (Default value)

In PostgreSQL, the CREATE TABLE and CREATE INDEX statements supports TABLESPACE clauses. However, if the specified tablespace does not exist in PostgreSQL, the CREATE TABLE and CREATE INDEX statements will fail to be executed. Before compiling the migration scripts on PostgreSQL, you need to create the required tablespace.

TRUE

Comment TABLESPACE.

The TABLESPACE clauses are commented. The default tablespace is used when a table or index is created.

pkg_naming

Package

It is applicable for packages. Based on parameter configuration, you can use packages as schemas or merge package names along with procedure and function names.

Package

pkg_as_schema

Convert packages to schemas.

PostgreSQL does not support packages. Package stored procedures and functions are converted into independent stored procedures and functions. These objects will be created in schemas with the same name as packages. They are not part of packages, so there may be performance issues.

grant_support

GRANT

Object privileges

Table, view, index, stored procedure, and function

ignore

Do not convert GRANT statements. The scripts will be retained unchanged. (Default value)

In PostgreSQL, object privileges are granted separately. This configuration will ignore the migration and scripts will be retained unchanged.

comment

Comment the entire GRANT statements.

In PostgreSQL, object privileges are granted separately. This configuration will comment the entire GRANT statements.

sqlplus_unsupported_command

SQL PLUS

PostgreSQL does not fully support SQL PLUS commands. This configuration will handle such type of requirements.

SQL PLUS commands

IGNORE

Ignore the migration. The script will be retained as it is.

PostgreSQL does not support SQL PLUS commands. This configuration will ignore the script.

COMMENT

Comment the SQL PLUS commands. (Default value)

PostgreSQL does not support SQL PLUS commands. This configuration will comment the script.

ERROR

Raise an error.

PostgreSQL does not support SQL PLUS commands. This configuration will raise an error.

unlogged_table_support

NOLOGGING table

PostgreSQL does not support NOLOGGING tables. This configuration converts NOLOGGING tables to UNLOGGED tables.

Table

COMMENT

Comment NOLOGGING. (Default value)

PostgreSQL does not support NOLOGGING tables. This configuration will comment NOLOGGING and performance is affected.

UNLOGGED

Convert NOLOGGING to UNLOGGED.

PostgreSQL does not support NOLOGGING tables. This configuration converts NOLOGGING to UNLOGGED and does not affect performance.

external_global_user_support

Global or external users

Based on configuration, you can ignore global or external users, comment global or external users, or convert global or external users to common database users.

System

IGNORE

Ignore the statements. (Default value)

PostgreSQL does not support global or external users. This configuration will log an error during migration and ignore the statements.

COMMENT

Comment the entire CREATE USER statements.

PostgreSQL does not support global or external users. This configuration will comment CREATE USER statements. You should manually update the users as needed.

DBUSER

Convert global or external users to common database users.

PostgreSQL does not support global or external users. This configuration will convert global or external users to common database users.

user_profile_support

PROFILE in CREATE USER statements

It is used to support the use of PROFILE in CREATE USER statements. Base on the configuration, you can choose to ignore the statements, comment the statements, or raise an error.

System

IGNORE

Ignore the statements. (Default value)

PostgreSQL does not support PROFILE. This configuration will ignore the statements.

COMMENT

Comment the CREATE USER statements partially.

PostgreSQL does not support PROFILE. This configuration will comment the CREATE USER statements partially.

ERROR

Raise an error.

PostgreSQL does not support PROFILE. This configuration will raise an error.

user_edition_support

EDITION in CREATE USER statements

It is used to support the use of EDITION in CREATE USER statements. Base on the configuration, you can choose to ignore the statements, comment the statements, or raise an error.

System

IGNORE

Ignore the statements. (Default value)

PostgreSQL does not support EDITION. This configuration will ignore the statements.

COMMENT

Comment the CREATE USER statements partially.

PostgreSQL does not support EDITION. This configuration will comment the CREATE USER statements partially.

ERROR

Raise an error.

PostgreSQL does not support EDITION. This configuration will raise an error.

role_identified_support

Use IDENTIFIED BY in CREATE ROLE statements.

This configuration is used to ensure role security.

System

RETAIN

Ignore the statements.

PostgreSQL does not fully support IDENTIFIED BY in the CREATE ROLE statements. This configuration will ignore the statements.

COMMENT

Comment the CREATE ROLE statements partially.

PostgreSQL does not fully support IDENTIFIED BY in the CREATE ROLE statements. This configuration will comment the CREATE ROLE statements partially.

Password

Use the password generated by the system to create a role.

PostgreSQL does not fully support IDENTIFIED BY in the CREATE ROLE statements. This configuration uses the password generated by the system to create a role.

ERROR

Raise an error. (Default value)

PostgreSQL does not fully support IDENTIFIED BY in the CREATE ROLE statements. This configuration will raise an error.

local_temp_tablespace_support

LOCAL TEMPORARY TABLESPACE

This configuration is used to support LOCAL TEMPORARY TABLESPACE in CREATE USER or CREATE ROLE statements. Base on the configuration, you can choose to ignore the statements, comment the statements, or raise an error.

System

RETAIN

Ignore the statements.

PostgreSQL does not support LOCAL TEMPORARY TABLESPACE. This configuration will ignore the statements.

COMMENT

Comment CREATE ROLE or CREATE USER statements partially.

PostgreSQL does not support LOCAL TEMPORARY TABLESPACE. This configuration will comment CREATE USER or CREATE ROLE statements partially.

ERROR

Raise an error. (Default value)

PostgreSQL does not support LOCAL TEMPORARY TABLESPACE. This configuration will raise an error.

user_identified_support

Use IDENTIFIED BY in the CREATE USER statements.

This configuration is used to support CREATE USER statements.

System

RETAIN

Ignore the statements. (Default value)

PostgreSQL does not fully support IDENTIFIED BY in CREATE USER statements. This configuration will ignore the statements.

MIGRATE

Convert IDENTIFIED BY to PASSWORD.

PostgreSQL does not fully support IDENTIFIED BY in CREATE USER statements. This configuration will convert IDENTIFIED BY to PASSWORD.

ERROR

Raise an error.

PostgreSQL does not fully support IDENTIFIED BY in CREATE USER statements. This configuration will raise an error.