PostgreSQL 8.0.1 Documentation | ||||
---|---|---|---|---|
Prev | Fast Backward | Fast Forward | Next |
Chapter 37. PL/Perl - Perl Procedural Language
- Table of Contents
- 37.1. PL/Perl Functions and Arguments
- 37.2. Database Access from PL/Perl
- 37.3. Data Values in PL/Perl
- 37.4. Global Values in PL/Perl
- 37.5. Trusted and Untrusted PL/Perl
- 37.6. PL/Perl Triggers
- 37.7. Limitations and Missing Features
PL/Perl is a loadable procedural language that enables you to write PostgreSQL functions in the Perl programming language.
To install PL/Perl in a particular database, use createlang plperl dbname.
Tip: If a language is installed into template1, all subsequently created databases will have the language installed automatically.
Note: Users of source packages must specially enable the build of PL/Perl during the installation process. (Refer to Section 14.1 for more information.) Users of binary packages might find PL/Perl in a separate subpackage.
37.1. PL/Perl Functions and Arguments
To create a function in the PL/Perl language, use the standard syntax:
The body of the function is ordinary Perl code.
The syntax of the CREATE FUNCTION command requires the function body to be written as a string constant. It is usually most convenient to use dollar quoting (see Section 4.1.2.2) for the string constant. If you choose to use regular single-quoted string constant syntax, you must escape single quote marks (') and backslashes (\) used in the body of the function, typically by doubling them (see Section 4.1.2.1).
Arguments and results are handled as in any other Perl subroutine: arguments are passed in @_, and a result value is returned with return or as the last expression evaluated in the function.
For example, a function returning the greater of two integer values could be defined as:
If an SQL null value is passed to a function, the argument value will appear as "undefined" in Perl. The above function definition will not behave very nicely with null inputs (in fact, it will act as though they are zeroes). We could add STRICT to the function definition to make PostgreSQL do something more reasonable: if a null value is passed, the function will not be called at all, but will just return a null result automatically. Alternatively, we could check for undefined inputs in the function body. For example, suppose that we wanted perl_max
with one null and one nonnull argument to return the nonnull argument, rather than a null value:
As shown above, to return an SQL null value from a PL/Perl function, return an undefined value. This can be done whether the function is strict or not.
Composite-type arguments are passed to the function as references to hashes. The keys of the hash are the attribute names of the composite type. Here is an example:
A PL/Perl function can return a composite-type result using the same approach: return a reference to a hash that has the required attributes. For example,
Any columns in the declared result data type that are not present in the hash will be returned as NULLs.
PL/Perl functions can also return sets of either scalar or composite types. To do this, return a reference to an array that contains either scalars or references to hashes, respectively. Here are some simple examples:
Note that when you do this, Perl will have to build the entire array in memory; therefore the technique does not scale to very large result sets.
PL/Perl does not currently have full support for domain types: it treats a domain the same as the underlying scalar type. This means that constraints associated with the domain will not be enforced. This is not an issue for function arguments, but it is a hazard if you declare a PL/Perl function as returning a domain type.