Peter Eisentraut

Sun Microsystems

PORTING APPLICATIONS FROM ORACLE TO POSTGRESQL

Why? Reasons for Porting

Number One reasons: Cost

Most people appear to come from Oracle and Informix

But porting can be pretty difficult

A rewrite might be better

Tools

Essential:

orafce

ora2pg

Also useful:

TOra

DBD::Oracle

Oracle Instant Client

Critical Syntax Differences

Identifier quoting: foo vs. foo vs. FOO vs. FOO

better not to mix quoted and unquoted

SELECT foo [AS] bar FROM ...

fixed in PostgreSQL 8.4

MINUS instead of EXCEPT

search and replace

SELECT ... FROM dual

fixed through orafce

SQL key words

Porting the SQL Schema

Many things work without problems:

Table definition

Columns

Constraints

Views

Many queries

Locking, concurrency control

Data Types

varchar2 varchar or text

clob, long varchar or text

nvarchar2, nclob varchar or text

number numeric or bigint or int or smallint or double precision or real (bug potential)

binary_float, binary_double real/double precision

blob, raw, long raw (bytea)

date date or timestamp

Data Types Development Plan

Implement missing SQL standard types in PostgreSQL:

blob, clob, nclob

Add some Oracle types to orafce:

varchar2, nvarchar2

long

number

binary_float, binary_double

Built-in Functions

PostgreSQL supports many compatibility functions.

orafce supports even more compatibility functions.

It's easy to write your own.

Manual work necessary for:

sysdate current_timestamp or localtimestamp

decode CASE

seqname.nextval nextval('seqname')

Functions with Default Parameters

CREATE FUNCTION foo (a int, b int, c int = 0) ...

becomes

CREATE FUNCTION foo (a int, b int, c int) ...

CREATE FUNCTION foo (a int, b int) ...
AS $$ SELECT foo(a, b, 0) $$;

This doesn't always work for the general case.

PostgreSQL might support this better in the future.

Outer Joins

Oracle supports SQL join syntax, but most people don't use it.

To port:

SELECT * FROM a, b WHERE a.x = b.y(+)

becomes

SELECT * FROM a LEFT JOIN b ON a.x = b.y

Po

Null Values

Oracle has NULL equivalent to ''

Therefore, '' = '' is not true

Causes all kinds of logical inconsistencies

Just hope your code doesn't rely too much on this

Triggers

Same concept, different syntax:

CREATE TRIGGER foo AFTER action ON table
AS BEGIN ... END;

becomes

CREATE OR REPLACE FUNCTION foo_tg()
RETURNS TRIGGER
LANGUAGE xxx
AS $$ ... $$;

CREATE TRIGGER foo AFTER action ON table
EXECUTE PROCEDURE foo_tg();

Date/Time Processing

Remember: date might be timestamp

Then date + int might become timestamp + int, which doesn't work.

to_char() is mostly compatible, but less robust

NLS_DATE_FORMAT locale settings

orafce helps: to_char(), last_day(), add_months(), ...

Code rewrite is sometimes preferrable.

ROWNUM and ROWID

ROWNUM:

Rewrite using LIMIT, or

Use generate_series, or

Handle in the client, or

Window functions in 8.4?

ROWID:

Similar to ctid

Not portable

Query can usually be rewritten

Sometimes used as workaround for lack of joins in UPDATE or DELETE

Other Porting Issues

Indexes

Optimizer hints

Encodings, locales

Partitioning

Things That Won't Work Easily

CONNECT BY

Window functions

Materialized views, snapshots

Database links

Autonomous transactions

Synonyms

Virtual Private Database (VPD)

XML

(= your project might balloon if you have a lot of these)

PL/SQL vs. PL/pgSQL

Very similar, but not really that compatible

Count on having to manually touch up every single function/procedure

See also http://www.postgresql.org/docs/current/static/plpgsql-porting.html

PL/SQL vs. PL/pgSQL: Major Diffs

CREATE FUNCTION ... RETURN RETURNS

Quote function body ($$ ... $$)

Add DECLARE for variable definitions block

Columns vs. variables name clashes

Packages

Package variables

cursorname%ROWTYPE RECORD

PERFORM procname();

PL/SQL vs. PL/pgSQL: More Diffs

Intra-procedure COMMIT and ROLLBACK

Exception handling

Implicit rollback in PostgreSQL

Oracle code often has complex savepoint-using code to achieve the same delete it.

Exception names and error codes are different.

NO_DATA_FOUND exceptions use SELECT INTO STRICT or IF NOT FOUND

sqlplus vs. psql

sqlplus is more powerful for scripting.

psql is better for interactive use.

With careful naming conventions and use of variables, some scripts can be ported.

Better rewrite all the scripts.

Other Things to Think About

Backup, recovery

Setup scripts

Maintenance scripts

Test suite

Long-term code maintenance

Legacy environments

Adjusting client code

Conclusions

It's possible to write portable Oracle applications, but most people don't do it.

Porting projects range from trivial to nearly impossible.

Rewrites or complete redesigns might work better.

Careful evaluation and planning is advisable.

Contribute

Porting projects are a good source for feature ideas and bug fixes.

Contribute your improvements:

ora2pg

orafce

PL/pgSQL

PL/Java

Record experiences in wiki

http://wiki.postgresql.org/wiki/Oracle_Compatibility_Tasks

PORTING ORACLE APPLICATIONS TO POSTGRESQL

Peter Eisentraut

peter.eisentraut@sun.com

Sun Microsystems, Inc.

Page

Click to edit the title text format

Click to edit the outline text format

Second Outline Level

Click to edit the notes format

Page

Click to edit the title text format

Presenters Name

Presenters Title

Presenters Company

Click to edit the notes format

Page