PostgreSQL 8.0.0rc2 Documentation
Prev | Fast Backward | Chapter 36. PL/pgSQL - SQL Procedural Language | Fast Forward | Next

# 36.11. Porting from Oracle PL/SQL

This section explains differences between PostgreSQL's PL/pgSQL language and Oracle's PL/SQL language, to help developers who port applications from Oracle® to PostgreSQL.

PL/pgSQL is similar to PL/SQL in many aspects. It is a block-structured, imperative language, and all variables have to be declared. Assignments, loops, conditionals are similar. The main differences you should keep in mind when porting from PL/SQL to PL/pgSQL are:

- There are no default values for parameters in PostgreSQL.

- You can overload function names in PostgreSQL. This is often used to work around the lack of default parameters.

- No need for cursors in PL/pgSQL, just put the query in the `FOR` statement. (See Example 36-4.)

- In PostgreSQL you need to use dollar quoting or escape single quotes in the function body. See Section 36.2.1.

- Instead of packages, use schemas to organize your functions into groups.

## 36.11.1. Porting Examples

Example 36-3 shows how to port a simple function from PL/SQL to PL/pgSQL.

Example 36-3. Porting a Simple Function from PL/SQL to PL/pgSQL

Here is an Oracle PL/SQL function:

    CREATE OR REPLACE FUNCTION cs_fmt_browser_version(v_name IN varchar,
                                                      v_version IN varchar)
    RETURN varchar IS
    BEGIN
        IF v_version IS NULL THEN
            RETURN v_name;
        END IF;
        RETURN v_name || '/' || v_version;
    END;
    /
    show errors;

Let's go through this function and see the differences to PL/pgSQL:

- Oracle can have `IN`, `OUT`, and `INOUT` parameters passed to functions. `INOUT`, for example, means that the parameter will receive a value and return another. PostgreSQL only has `IN` parameters, and hence there is no specification of the parameter kind.

- The `RETURN` key word in the function prototype (not the function body) becomes `RETURNS` in PostgreSQL. Also, `IS` becomes `AS`, and you need to add a `LANGUAGE` clause because PL/pgSQL is not the only possible function language.

- In PostgreSQL, the function body is considered to be a string literal, so you need to use quote marks or dollar quotes around it. This substitutes for the terminating `/` in the Oracle approach.

- The `show errors` command does not exist in PostgreSQL, and is not needed since errors are reported automatically.

This is how this function would look when ported to PostgreSQL:

    CREATE OR REPLACE FUNCTION cs_fmt_browser_version(v_name varchar,
                                                      v_version varchar)
    RETURNS varchar AS $$
    BEGIN
        IF v_version IS NULL THEN
            RETURN v_name;
        END IF;
        RETURN v_name || '/' || v_version;
    END;
    $$ LANGUAGE plpgsql;

Example 36-4 shows how to port a function that creates another function and how to handle the ensuing quoting problems.

Example 36-4. Porting a Function that Creates Another Function from PL/SQL to PL/pgSQL

The following procedure grabs rows from a `SELECT` statement and builds a large function with the results in `IF` statements, for the sake of efficiency. Notice particularly the differences in the cursor and the `FOR` loop.

This is the Oracle version:

    CREATE OR REPLACE PROCEDURE cs_update_referrer_type_proc IS
        CURSOR referrer_keys IS
            SELECT * FROM cs_referrer_keys
            ORDER BY try_order;

        func_cmd VARCHAR(4000);
    BEGIN
        func_cmd := 'CREATE OR REPLACE FUNCTION cs_find_referrer_type(v_host IN VARCHAR,
                     v_domain IN VARCHAR, v_url IN VARCHAR) RETURN VARCHAR IS BEGIN';

        FOR referrer_key IN referrer_keys LOOP
            func_cmd := func_cmd ||
              ' IF v_' || referrer_key.kind
              || ' LIKE ''' || referrer_key.key_string
              || ''' THEN RETURN ''' || referrer_key.referrer_type
              || '''; END IF;';
        END LOOP;

        func_cmd := func_cmd || ' RETURN NULL; END;';

        EXECUTE IMMEDIATE func_cmd;
    END;
    /
    show errors;

Here is how this function would end up in PostgreSQL:

    CREATE OR REPLACE FUNCTION cs_update_referrer_type_proc() RETURNS void AS $func$
    DECLARE
        referrer_key RECORD;  -- declare a generic record to be used in a FOR
        func_body text;
        func_cmd text;
    BEGIN
        func_body := 'BEGIN' ;

        -- Notice how we scan through the results of a query in a FOR loop
        -- using the FOR <record> construct.

        FOR referrer_key IN SELECT * FROM cs_referrer_keys ORDER BY try_order LOOP
            func_body := func_body ||
              ' IF v_' || referrer_key.kind
              || ' LIKE ' || quote_literal(referrer_key.key_string)
              || ' THEN RETURN ' || quote_literal(referrer_key.referrer_type)
              || '; END IF;' ;
        END LOOP;

        func_body := func_body || ' RETURN NULL; END;';

        func_cmd :=
          'CREATE OR REPLACE FUNCTION cs_find_referrer_type(v_host varchar,
                                                            v_domain varchar,
                                                            v_url varchar)
            RETURNS varchar AS '
          || quote_literal(func_body)
          || ' LANGUAGE plpgsql;' ;

        EXECUTE func_cmd;
        RETURN;
    END;
    $func$ LANGUAGE plpgsql;

Notice how the body of the function is built separately and passed through `quote_literal` to double any quote marks in it. This technique is needed because we cannot safely use dollar quoting for defining the new function: we do not know for sure what strings will be interpolated from the `referrer_key.key_string` field. (We are assuming here that `referrer_key.kind` can be trusted to always be `host`, `domain`, or `url`, but `referrer_key.key_string` might be anything, in particular it might contain dollar signs.) This function is actually an improvement on the Oracle original, because it will not generate broken code when `referrer_key.key_string` or `referrer_key.referrer_type` contain quote marks.

Example 36-5 shows how to port a function with `OUT` parameters and string manipulation. PostgreSQL does not have an `instr` function, but you can work around it using a combination of other functions. In Section 36.11.3 there is a PL/pgSQL implementation of `instr` that you can use to make your porting easier.

Example 36-5. Porting a Procedure With String Manipulation and `OUT` Parameters from PL/SQL to PL/pgSQL

The following Oracle PL/SQL procedure is used to parse a URL and return several elements (host, path, and query). In PostgreSQL, functions can return only one value. One way to work around this is to make the return value a composite type (row type).

This is the Oracle version:

    CREATE OR REPLACE PROCEDURE cs_parse_url(
        v_url IN VARCHAR,
        v_host OUT VARCHAR,  -- This will be passed back
        v_path OUT VARCHAR,  -- This one too
        v_query OUT VARCHAR) -- And this one
    IS
        a_pos1 INTEGER;
        a_pos2 INTEGER;
    BEGIN
        v_host := NULL;
        v_path := NULL;
        v_query := NULL;
        a_pos1 := instr(v_url, '//');

        IF a_pos1 = 0 THEN
            RETURN;
        END IF;
        a_pos2 := instr(v_url, '/', a_pos1 + 2);
        IF a_pos2 = 0 THEN
            v_host := substr(v_url, a_pos1 + 2);
            v_path := '/';
            RETURN;
        END IF;

        v_host := substr(v_url, a_pos1 + 2, a_pos2 - a_pos1 - 2);
        a_pos1 := instr(v_url, '?', a_pos2 + 1);

        IF a_pos1 = 0 THEN
            v_path := substr(v_url, a_pos2);
            RETURN;
        END IF;

        v_path := substr(v_url, a_pos2, a_pos1 - a_pos2);
        v_query := substr(v_url, a_pos1 + 1);
    END;
    /
    show errors;

Here is a possible translation into PL/pgSQL:

    CREATE TYPE cs_parse_url_result AS (
        v_host VARCHAR,
        v_path VARCHAR,
        v_query VARCHAR
    );

    CREATE OR REPLACE FUNCTION cs_parse_url(v_url VARCHAR)
    RETURNS cs_parse_url_result AS $$
    DECLARE
        res cs_parse_url_result;
        a_pos1 INTEGER;
        a_pos2 INTEGER;
    BEGIN
        res.v_host := NULL;
        res.v_path := NULL;
        res.v_query := NULL;
        a_pos1 := instr(v_url, '//');

        IF a_pos1 = 0 THEN
            RETURN res;
        END IF;
        a_pos2 := instr(v_url, '/', a_pos1 + 2);
        IF a_pos2 = 0 THEN
            res.v_host := substr(v_url, a_pos1 + 2);
            res.v_path := '/';
            RETURN res;
        END IF;

        res.v_host := substr(v_url, a_pos1 + 2, a_pos2 - a_pos1 - 2);
        a_pos1 := instr(v_url, '?', a_pos2 + 1);

        IF a_pos1 = 0 THEN
            res.v_path := substr(v_url, a_pos2);
            RETURN res;
        END IF;

        res.v_path := substr(v_url, a_pos2, a_pos1 - a_pos2);
        res.v_query := substr(v_url, a_pos1 + 1);
        RETURN res;
    END;
    $$ LANGUAGE plpgsql;

This function could be used like this:

    SELECT * FROM cs_parse_url('http://foobar.com/query.cgi?baz');

Example 36-6 shows how to port a procedure that uses numerous features that are specific to Oracle.

Example 36-6. Porting a Procedure from PL/SQL to PL/pgSQL

The Oracle version:

    CREATE OR REPLACE PROCEDURE cs_create_job(v_job_id IN INTEGER) IS
        a_running_job_count INTEGER;
        PRAGMA AUTONOMOUS_TRANSACTION;(1)
    BEGIN
        LOCK TABLE cs_jobs IN EXCLUSIVE MODE;(2)

        SELECT count(*) INTO a_running_job_count FROM cs_jobs WHERE end_stamp IS NULL;

        IF a_running_job_count > 0 THEN
            COMMIT; -- free lock(3)
            raise_application_error(-20000, 'Unable to create a new job: a job is currently running.');
        END IF;

        DELETE FROM cs_active_job;
        INSERT INTO cs_active_job(job_id) VALUES (v_job_id);

        BEGIN
            INSERT INTO cs_jobs (job_id, start_stamp) VALUES (v_job_id, sysdate);
        EXCEPTION
            WHEN dup_val_on_index THEN NULL; -- don't worry if it already exists
        END;
        COMMIT;
    END;
    /
    show errors

Procedures like this can easily be converted into PostgreSQL functions returning `void`. This procedure in particular is interesting because it can teach us some things:

(1)
  There is no `PRAGMA` statement in PostgreSQL.
(2)
  If you do a `LOCK TABLE` in PL/pgSQL, the lock will not be released until the calling transaction is finished.
(3)
  You cannot issue `COMMIT` in a PL/pgSQL function. The function is running within some outer transaction and so `COMMIT` would imply terminating the function's execution. However, in this particular case it is not necessary anyway, because the lock obtained by the `LOCK TABLE` will be released when we raise an error.

This is how we could port this procedure to PL/pgSQL:

    CREATE OR REPLACE FUNCTION cs_create_job(v_job_id integer) RETURNS void AS $$
    DECLARE
        a_running_job_count integer;
    BEGIN
        LOCK TABLE cs_jobs IN EXCLUSIVE MODE;

        SELECT count(*) INTO a_running_job_count FROM cs_jobs WHERE end_stamp IS NULL;

        IF a_running_job_count > 0 THEN
            RAISE EXCEPTION 'Unable to create a new job: a job is currently running';(1)
        END IF;

        DELETE FROM cs_active_job;
        INSERT INTO cs_active_job(job_id) VALUES (v_job_id);

        BEGIN
            INSERT INTO cs_jobs (job_id, start_stamp) VALUES (v_job_id, now());
        EXCEPTION
            WHEN unique_violation THEN (2)
                -- don't worry if it already exists
        END;

        RETURN;
    END;
    $$ LANGUAGE plpgsql;

(1)
  The syntax of `RAISE` is considerably different from Oracle's similar statement.
(2)
  The exception names supported by PL/pgSQL are different from Oracle's. The set of built-in exception names is much larger (see Appendix A). There is not currently a way to declare user-defined exception names.

The main functional difference between this procedure and the Oracle equivalent is that the exclusive lock on the `cs_jobs` table will be held until the calling transaction completes. Also, if the caller later aborts (for example due to an error), the effects of this procedure will be rolled back.

## 36.11.2. Other Things to Watch For

This section explains a few other things to watch for when porting Oracle PL/SQL functions to PostgreSQL.

### 36.11.2.1. Implicit Rollback after Exceptions

In PL/pgSQL, when an exception is caught by an `EXCEPTION` clause, all database changes since the block's `BEGIN` are automatically rolled back. That is, the behavior is equivalent to what you'd get in Oracle with

        BEGIN
            SAVEPOINT s1;
            ... code here ...
        EXCEPTION
            WHEN ... THEN
                ROLLBACK TO s1;
                ... code here ...
            WHEN ... THEN
                ROLLBACK TO s1;
                ... code here ...
        END;

If you are translating an Oracle procedure that uses `SAVEPOINT` and `ROLLBACK TO` in this style, your task is easy: just omit the `SAVEPOINT` and `ROLLBACK TO`. If you have a procedure that uses `SAVEPOINT` and `ROLLBACK TO` in a different way then some actual thought will be required.

### 36.11.2.2. `EXECUTE`

The PL/pgSQL version of `EXECUTE` works similarly to the PL/SQL version, but you have to remember to use `quote_literal(text)` and `quote_string(text)` as described in Section 36.6.5. Constructs of the type `EXECUTE 'SELECT * FROM $1';` will not work unless you use these functions.

### 36.11.2.3. Optimizing PL/pgSQL Functions

PostgreSQL gives you two function creation modifiers to optimize execution: "volatility" (whether the function always returns the same result when given the same arguments) and "strictness" (whether the function returns null if any argument is null). Consult the CREATE FUNCTION reference page for details.

When making use of these optimization attributes, your `CREATE FUNCTION` statement might look something like this:

    CREATE FUNCTION foo(...) RETURNS integer AS $$
    ...
    $$ LANGUAGE plpgsql STRICT IMMUTABLE;

## 36.11.3. Appendix

This section contains the code for a set of Oracle-compatible `instr` functions that you can use to simplify your porting efforts.

    --
    -- instr functions that mimic Oracle's counterpart
    -- Syntax: instr(string1, string2, [n], [m]) where [] denotes optional parameters.
    --
    -- Searches string1 beginning at the nth character for the mth occurrence
    -- of string2.  If n is negative, search backwards.  If m is not passed,
    -- assume 1 (search starts at first character).
    --

    CREATE FUNCTION instr(varchar, varchar) RETURNS integer AS $$
    DECLARE
        pos integer;
    BEGIN
        pos:= instr($1, $2, 1);
        RETURN pos;
    END;
    $$ LANGUAGE plpgsql STRICT IMMUTABLE;

    CREATE FUNCTION instr(string varchar, string_to_search varchar, beg_index integer)
    RETURNS integer AS $$
    DECLARE
        pos integer NOT NULL DEFAULT 0;
        temp_str varchar;
        beg integer;
        length integer;
        ss_length integer;
    BEGIN
        IF beg_index > 0 THEN
            temp_str := substring(string FROM beg_index);
            pos := position(string_to_search IN temp_str);

            IF pos = 0 THEN
                RETURN 0;
            ELSE
                RETURN pos + beg_index - 1;
            END IF;
        ELSE
            ss_length := char_length(string_to_search);
            length := char_length(string);
            beg := length + beg_index - ss_length + 2;

            WHILE beg > 0 LOOP
                temp_str := substring(string FROM beg FOR ss_length);
                pos := position(string_to_search IN temp_str);

                IF pos > 0 THEN
                    RETURN beg;
                END IF;

                beg := beg - 1;
            END LOOP;

            RETURN 0;
        END IF;
    END;
    $$ LANGUAGE plpgsql STRICT IMMUTABLE;

    CREATE FUNCTION instr(string varchar, string_to_search varchar,
                          beg_index integer, occur_index integer)
    RETURNS integer AS $$
    DECLARE
        pos integer NOT NULL DEFAULT 0;
        occur_number integer NOT NULL DEFAULT 0;
        temp_str varchar;
        beg integer;
        i integer;
        length integer;
        ss_length integer;
    BEGIN
        IF beg_index > 0 THEN
            beg := beg_index;
            temp_str := substring(string FROM beg_index);

            FOR i IN 1..occur_index LOOP
                pos := position(string_to_search IN temp_str);

                IF i = 1 THEN
                    beg := beg + pos - 1;
                ELSE
                    beg := beg + pos;
                END IF;

                temp_str := substring(string FROM beg + 1);
            END LOOP;

            IF pos = 0 THEN
                RETURN 0;
            ELSE
                RETURN beg;
            END IF;
        ELSE
            ss_length := char_length(string_to_search);
            length := char_length(string);
            beg := length + beg_index - ss_length + 2;

            WHILE beg > 0 LOOP
                temp_str := substring(string FROM beg FOR ss_length);
                pos := position(string_to_search IN temp_str);

                IF pos > 0 THEN
                    occur_number := occur_number + 1;

                    IF occur_number = occur_index THEN
                        RETURN beg;
                    END IF;
                END IF;

                beg := beg - 1;
            END LOOP;

            RETURN 0;
        END IF;
    END;
    $$ LANGUAGE plpgsql STRICT IMMUTABLE;

Prev | Home | Next
Trigger Procedures | Up | PL/Tcl - Tcl Procedural Language