1. 1 Peter Eisentraut Sun Microsystems PORTING APPLICATIONS FROM ORACLE TO POSTGRESQL 1

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

3. 3 Tools Essential: orafce ora2pg Also useful: TOra DBD::Oracle Oracle Instant Client

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

5. 5 Porting the SQL Schema Many things work without problems: Table definition Columns Constraints Views Many queries Locking, concurrency control

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

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

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

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

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

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

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

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

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

15. 15 Other Porting Issues Indexes Optimizer hints Encodings, locales Partitioning

16. 16 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)

17. 17 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 http://www.postgresql.org/docs/current/static/plpgsql- porting.html

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

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

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

21. 21 Other Things to Think About Backup, recovery Setup scripts Maintenance scripts Test suite Long-term code maintenance Legacy environments Adjusting client code

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

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

24. 24 PORTING ORACLE APPLICATIONS TO POSTGRESQL Peter Eisentraut peter.eisentraut@sun.com 24