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