Chapter 19. PL/pgSQL - SQL Procedural Language

Table of Contents
19.1. Overview
19.1.1. Advantages of Using PL/pgSQL
19.1.2. Developing in PL/pgSQL
19.2. Structure of PL/pgSQL
19.3. Declarations
19.3.1. Aliases for Function Parameters
19.3.2. Row Types
19.3.3. Records
19.3.4. Attributes
19.3.5. RENAME
19.4. Expressions
19.5. Basic Statements
19.5.1. Assignment
19.5.3. Executing an expression or query with no result
19.5.4. Executing dynamic queries
19.5.5. Obtaining result status
19.6. Control Structures
19.6.1. Returning from a function
19.6.2. Conditionals
19.6.3. Simple Loops
19.6.4. Looping Through Query Results
19.7. Cursors
19.7.1. Declaring Cursor Variables
19.7.2. Opening Cursors
19.7.3. Using Cursors
19.8. Errors and Messages
19.9. Trigger Procedures
19.10. Examples
19.11. Porting from Oracle PL/SQL
19.11.1. Main Differences
19.11.2. Porting Functions
19.11.3. Procedures
19.11.4. Packages
19.11.5. Other Things to Watch For
19.11.6. Appendix

PL/pgSQL is a loadable procedural language for the PostgreSQL database system.

This package was originally written by Jan Wieck. This documentation was in part written by Roberto Mello ().

19.1. Overview

The design goals of PL/pgSQL were to create a loadable procedural language that

The PL/pgSQL call handler parses the function's source text and produces an internal binary instruction tree the first time the function is called (within any one backend process). The instruction tree fully translates the PL/pgSQL statement structure, but individual SQL expressions and SQL queries used in the function are not translated immediately.

As each expression and SQL query is first used in the function, the PL/pgSQL interpreter creates a prepared execution plan (using the SPI manager's SPI_prepare and SPI_saveplan functions). Subsequent visits to that expression or query re-use the prepared plan. Thus, a function with conditional code that contains many statements for which execution plans might be required will only prepare and save those plans that are really used during the lifetime of the database connection. This can substantially reduce the total amount of time required to parse, and generate query plans for the statements in a procedural language function. A disadvantage is that errors in a specific expression or query may not be detected until that part of the function is reached in execution.

Once PL/pgSQL has made a query plan for a particular query in a function, it will re-use that plan for the life of the database connection. This is usually a win for performance, but it can cause some problems if you dynamically alter your database schema. For example:

    -- Declarations
    PERFORM my_function();
' LANGUAGE 'plpgsql';

If you execute the above function, it will reference the OID for my_function() in the query plan produced for the PERFORM statement. Later, if you drop and re-create my_function(), then populate() will not be able to find my_function() anymore. You would then have to re-create populate(), or at least start a new database session so that it will be compiled afresh.

Because PL/pgSQL saves execution plans in this way, queries that appear directly in a PL/pgSQL function must refer to the same tables and fields on every execution; that is, you cannot use a parameter as the name of a table or field in a query. To get around this restriction, you can construct dynamic queries using the PL/pgSQL EXECUTE statement --- at the price of constructing a new query plan on every execution.

Note: The PL/pgSQL EXECUTE statement is not related to the EXECUTE statement supported by the PostgreSQL backend. The backend EXECUTE statement cannot be used within PL/pgSQL functions (and is not needed).

Except for input/output conversion and calculation functions for user defined types, anything that can be defined in C language functions can also be done with PL/pgSQL. It is possible to create complex conditional computation functions and later use them to define operators or use them in functional indexes.

19.1.1. Advantages of Using PL/pgSQL Better Performance

SQL is the language PostgreSQL (and most other relational databases) use as query language. It's portable and easy to learn. But every SQL statement must be executed individually by the database server.

That means that your client application must send each query to the database server, wait for it to process it, receive the results, do some computation, then send other queries to the server. All this incurs inter-process communication and may also incur network overhead if your client is on a different machine than the database server.

With PL/pgSQL you can group a block of computation and a series of queries inside the database server, thus having the power of a procedural language and the ease of use of SQL, but saving lots of time because you don't have the whole client/server communication overhead. This can make for a considerable performance increase. SQL Support

PL/pgSQL adds the power of a procedural language to the flexibility and ease of SQL. With PL/pgSQL you can use all the data types, columns, operators and functions of SQL. Portability

Because PL/pgSQL functions run inside PostgreSQL, these functions will run on any platform where PostgreSQL runs. Thus you can reuse code and reduce development costs.

19.1.2. Developing in PL/pgSQL

Developing in PL/pgSQL is pretty straight forward, especially if you have developed in other database procedural languages, such as Oracle's PL/SQL. Two good ways of developing in PL/pgSQL are:

  • Using a text editor and reloading the file with psql

  • Using PostgreSQL's GUI Tool: PgAccess

One good way to develop in PL/pgSQL is to simply use the text editor of your choice to create your functions, and in another window, use psql (PostgreSQL's interactive monitor) to load those functions. If you are doing it this way, it is a good idea to write the function using CREATE OR REPLACE FUNCTION. That way you can reload the file to update the function definition. For example:

' LANGUAGE 'plpgsql';

While running psql, you can load or reload such a function definition file with

    \i filename.sql

and then immediately issue SQL commands to test the function.

Another good way to develop in PL/pgSQL is using PostgreSQL's GUI tool: PgAccess. It does some nice things for you, like escaping single-quotes, and making it easy to recreate and debug functions.