Unsupported features

EDB Postgres Advanced Server offers complete support for some Oracle features and partial support for others. Migration Toolkit can’t migrate any object that uses an unsupported feature.

In some cases, Migration Toolkit can migrate objects that use features that offer partial compatibility. In other cases, EDB Postgres Advanced Server supports suitable workarounds.

Full-text search is an example of functionality that isn’t fully compatible with Oracle. The EDB Postgres Advanced Server database has included support for full-text search for quite some time, but the implementation is different from Oracle’s. Migration Toolkit can’t migrate objects that use this feature.

EDB Postgres Advanced Server doesn’t yet support other features. Features in this category include Automated Storage Management, table compression, and external tables. You can often implement a successful workaround:

  • You can replace Automated Storage Management with system-specific volume management software.

  • You can implement table compression by storing data in a tablespace that resides on a compressed filesystem.

  • External tables don't exist in EDB Postgres Advanced Server, but you can load flat text files into staging tables in the database. We recommend using the EDB\*Loader utility to load the data into an EDB Postgres Advanced Server database quickly.

  • When migrating multiple profiles from an Oracle database into EDB Postgres Advanced Server, you must manually assign the profile to a user or users when the migration completes.

Unsupported Postgres features

Migration Toolkit doesn’t support migration of the following Postgres features:

  • `OPERATOR CLASS`

  • `OPERATOR FAMILY`

For information about OPERATOR CLASS and OPERATOR FAMILY, see the PostgreSQL core documentation.

Frequently asked questions

Does Migration Toolkit support the migration of packages?

Migration Toolkit supports the migration of packages from an Oracle database into EDB Postgres Advanced Server. See Functionality overview for information about the migration support offered by EDB Postgres Advanced Server.

Is there a way to transfer only the data from the source database?

Yes. Data transfer is supported as part of an online or offline migration.

Does Migration Toolkit support migration of tables that contain data of the CLOB data type?

Migration Toolkit does support migration of tables containing data of the CLOB type.

Does EDB Postgres Advanced Server support the enum data type?

EDB Postgres Advanced Server doesn’t currently support the enum data type but will support it in future releases. Until then, you can use a check constraint to restrict the data added to an EDB Postgres Advanced Server database. A check constraint defines a list of valid values that a column can take.

The following code sample includes a simple example of a check constraint that restricts the value of a column to one of three dept types; sales, admin or technical.

CREATE TABLE emp (
   * emp_id INT NOT NULL PRIMARY KEY,
   * dept VARCHAR(255) NOT NULL,
   *  CHECK (dept IN ('sales', 'admin', 'technical'))
);

If you test the check constraint by entering a valid dept type, the INSERT statement works without error:

test=# INSERT INTO emp VALUES (7324, 'sales');

INSERT 0 1

If you try to insert a value not included in the constraint (support), EDB Postgres Advanced Server returns an error:

test=# INSERT INTO emp VALUES (7325, 'support');

ERROR: new row for relation "emp" violates check constraint "emp_dept_check"

Does EDB Postgres Advanced Server support materialized views?

Postgres doesn’t support materialized views compatible with Oracle databases. To set up a materialized view/summary table in Postgres you must manually create the triggers that maintain the summary table. Automatic query rewrite isn’t currently supported. You must make the application aware of the summary table’s existence.

When I try to migrate from a MySQL database that includes a TIME data type, I get the following error: Error Loading Data into Table: Bad format for Time. Does Postgres support MySQL ``TIME`` data types?

Postgres doesn’t have a problem storing TIME data types as long as the value of the hour component isn’t greater than 24.

Unlike Postgres, the MySQL TIME data type allows you to store a value that represents either a TIME or an INTERVAL value. A value stored in a MySQL TIME column that represents an INTERVAL value can potentially be out of the accepted range of a valid Postgres TIMESTAMP value. If, during the migration process, Postgres encounters a value stored in a TIME data column that it perceives as out of range, it returns an error.