Conversion of DDL Oracle to Postgres

Question

I have a very huge DDL script in Oracle of our existing Application, It has no Stored Procedures. Just Tables, Sequences and constraints.

What is the best way to convert it to Postgres?

Some people say its better to do it by hand, and some say there are free tools for it. Can anyone suggest me the best way to do it?

If it is by hand, please suggest me what changes have to be made.

Example of Oracle DDL is given below, Please notify the changes to be made while converting to Postgres for the below DDL.

-  DDL for Table ACTOR_ROLE_INFO
--------------------------------------------------------

  CREATE TABLE "PAYTM_RELEASE1"."ACTOR_ROLE_INFO" 
   (    "ACTOR_ROLE_ID" NUMBER, 
    "ACTOR_ID" NUMBER, 
    "ROLE_ID" NUMBER, 
    "STATUS" NUMBER, 
    "CREATED_BY" NUMBER, 
    "CREATED_ON" TIMESTAMP (6) WITH TIME ZONE, 
    "MODIFIED_BY" NUMBER, 
    "MODIFIED_ON" TIMESTAMP (6) WITH TIME ZONE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS" ;
--------------------------------------------------------
--  DDL for Table ACTOR_TYPES
--------------------------------------------------------

  CREATE TABLE "PAYTM_RELEASE1"."ACTOR_TYPES" 
   (    "ACTOR_TYPE_ID" NUMBER, 
    "ACTOR_TYPE" VARCHAR2(100 BYTE), 
    "ACTOR_DESCRIPTION" VARCHAR2(100 BYTE), 
    "CREATED_BY" NUMBER, 
    "CREATED_DATE" TIMESTAMP (6) WITH TIME ZONE, 
    "MODIFIED_BY" NUMBER, 
    "MODIFIED_DATE" TIMESTAMP (6) WITH TIME ZONE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "USERS" ;

Answer 1

Use Ora2PG http://sourceforge.net/projects/ora2pg/ to get started, but don't blindly use the resulting schema. As Craig suggested, take a look at the data types. The NUMBER to NUMERIC conversion while simple, leads to a much bigger footprint on disk. It also leads to much bigger index sizes which will slow the whole app down. Your resulting schema shouldn't contain any NUMERIC columns unless your app really needs the abritrary percision and it should be the exception, not the rule.