• Like
Porting Applications From Oracle To PostgreSQL
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Porting Applications From Oracle To PostgreSQL

  • 3,022 views
Published

presented at the European PGDay 2008

presented at the European PGDay 2008

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
3,022
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
92
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1.
    • Peter Eisentraut
        • Sun Microsystems
    PORTING APPLICATIONS FROM ORACLE TO POSTGRESQL
  • 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. Tools
    • Essential:
    • orafce
    • ora2pg
    • Also useful:
    • TOra
    • DBD::Oracle
    • Oracle Instant Client
  • 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. Porting the SQL Schema
    • Many things work without problems:
    • Table definition
    • Columns
    • Constraints
    • Views
    • Many queries
    • Locking, concurrency control
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Other Porting Issues
    • Indexes
    • Optimizer hints
    • Encodings, locales
    • Partitioning
  • 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. 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
  • 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. 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. 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. Other Things to Think About
    • Backup, recovery
    • Setup scripts
    • Maintenance scripts
    • Test suite
    • Long-term code maintenance
    • Legacy environments
    • Adjusting client code
  • 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. 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. PORTING ORACLE APPLICATIONS TO POSTGRESQL
    • Peter Eisentraut
      • [email_address]