Peter Eisentraut Sun Microsystems PORTING APPLICATIONS FROM ORACLE TO POSTGRESQL

Peter Eisentraut

Sun Microsystems

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

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

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

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

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

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

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')

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.

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

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

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();

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.

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

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

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)

CONNECT BY

Window functions

Materialized views, snapshots

Database links

Autonomous transactions

Synonyms

Virtual Private Database (VPD)

XML

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

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();

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

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.

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

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.

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 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 [email_address]

Peter Eisentraut

[email_address]