Antananarivo, Madagascar- April 20th, 2025

## Ora2Pg

Version 25.0 of Ora2Pg, a free and reliable tool used to migrate an
Oracle database to PostgreSQL, has been officially released and is
publicly available for download.

This major release fix several issues reported since last release and adds some
new features and improvements:

  * Add multiple assessment report format output at once.
  * Support more Oracle to PostgreSQL exception mapping.
  * Allow overriding of PG_SUPPORTS_* settings as they are set in the 
configuration file. PG_VERSION will have no effect in this case.
  * Add parsing of ALTER statement from file for the QUERY action.
  * Add support for oracle_fdw COPY using CSV format
  * Add parallel export of each partition. Until now all partitions of a 
partitioned table was exported serialy in a single process.
  * Allow online data migration to continue if the destination table does not 
exist when ON_ERROR_STOP is disabled.
  * Tables data export is now done using the current SCN to have the same 
snapshot of data between multiprocess export.
  * Add replacement of USERENV call with MODULE by current_setting with 
application_name.
  * Add support for data movement using psql copy selecting over oracle_fdw:
    - Type INSERT (when FDW_SERVER is set) preserves prior behaviour of both
      INSERT and COPY
    - Type COPY (when FDW_SERVER is set) uses a new mode of using the `psql`
      with `\copy` with `TO PROGRAM...FROM STDIN BINARY...BINARY`
  * Add support for oracle_fdw in combination with psql "\copy" and server-side 
COPY using BINARY stream for data movement. Brings both local and server-side 
oracle_fdw binary copy into one branch. Control over which mode is used is 
provided via ORACLE_FDW_COPY_MODE configuration, which defaults to "local".
  * Convert DBMS_SQL cursor/parsing/execute simple form to PostgreSQL dynamic 
query execution.
  * Add replacement of the MOD operator.
  * Add some additional objects/difficulties assessment migration scores:
    - WHEN OTHER THEN exception clause that hide the real problem during 
migration.
    - 'SSSSS' and 'J' for to_char() that could need rewrites.
  * Add SCRIPT action to process sqlplus scripts as a whole, not line per line.
  * Change default settings in config file generated by the --init_project 
option with:
    - PG_NUMERIC_TYPE       0
    - NULL_EQUAL_EMPTY      1

New options and configuration directives:

  * Add --no_clean_comment option to not remove comments in source file before 
parsing. With huge DDL file with comments, it could take a very long time.
  * Add -O | --options used to override any configuration parameter, it can be 
used multiple time. Syntax:
            -O "PARAM1_NAME=value" -O "PARAM2_NAME=value"
    or
            -O "PARAM1_NAME=value|PARAM2_NAME=value"
  * Add option --no_start_scn to force Ora2Pg to not use a SCN to export data 
unless `--snc` is used. By default the current SCN is used to export data from 
all tables.
  * Add ORACLE_FDW_COPY_MODE configuration directive. When using Ora2Pg COPY 
with oracle_fdw it is possible to use two different modes:
    - 1) "local", which uses psql on the host running Ora2Pg for the "TO" 
binary stream;
    - 2) "server", which uses PostgreSQL server-side COPY for the "TO" binary 
stream.
  Both modes use psql for the "FROM STDIN BINARY". However, oracle_fdw binary 
copy into one branch. Control over which mode is used is "local" runs the psql 
"FROM STDIN BINARY" on host Ora2Pg is run from, whereas
    "server" runs the psql "FROM STDIN BINARY" on the PostgreSQL server. "local"
    mode should work on any PostgreSQL-based system, including managed 
offerings,
    which are not expected to support use of "server" mode due to permissions. 
The
    default is "local" as this is compatible with more configurations.
  * Add ORACLE_FDW_COPY_FORMAT configuration directive.
    When using Ora2Pg COPY with oracle_fdw it is possible to use either BINARY 
or
    CSV data format. BINARY provides better performance, however, requires exact
    data type matching between the FDW and destination table. CSV provides 
greater
    flexibiliity with respect to data type matching: if the FDW and destination
    data types are functionally-compatible the columns can be copied. The 
default
    is "binary".

For a complete list of change see 
[https://github.com/darold/ora2pg/blob/master/changelog](https://github.com/darold/ora2pg/blob/master/changelog)

Thanks to all contributors, they are all cited in the changelog file.

## Links  & Credits

I would like to thank all users who submitted patches and users
who reported bugs and feature requests, they are all cited
the ChangeLog file.

Ora2Pg is an open project. Any contribution to build a better tool is
welcome. You just have to send your ideas, features requests or patches
using the GitHub tools or directly to ora...@darold.net.

### Links:

* Website: [https://www.ora2pg.com/](https://www.ora2pg.com/)
* Download 
[https://github.com/darold/ora2pg/releases](https://github.com/darold/ora2pg/releases)
* Development: 
[https://github.com/darold/ora2pg](https://github.com/darold/ora2pg)
* Changelog: 
[https://github.com/darold/ora2pg/blob/master/changelog](https://github.com/darold/ora2pg/blob/master/changelog)
* Documentation: 
[https://github.com/darold/ora2pg/blob/master/README](https://github.com/darold/ora2pg/blob/master/README)

--------------

**About Ora2Pg** :

Ora2Pg is an easy and reliable tool to migrate from Oracle to PostgreSQL.
It is developed since 2001 and can export most of the Oracle objects into
PostgreSQL compatible code.

Ora2Pg works on any platform and is available under the GPL v3 licence.

Docs, Download & Support at [http://www.ora2pg.com/](http://www.ora2pg.com/)

Reply via email to