PostgreSQL 9.0.0 Documentation
Prev | Fast Backward | Chapter 41. PL/Perl - Perl Procedural Language | Fast Forward | Next

# 41.7. PL/Perl Under the Hood

## 41.7.1. Configuration

This section lists configuration parameters that affect PL/Perl. To set any of these parameters before PL/Perl has been loaded, it is necessary to have added "`plperl`" to the custom_variable_classes list in `postgresql.conf`.

`plperl.on_init` (`string`)

  Specifies Perl code to be executed when a Perl interpreter is first initialized and before it is specialized for use by `plperl` or `plperlu`. The SPI functions are not available when this code is executed. If the code fails with an error it will abort the initialization of the interpreter and propagate out to the calling query, causing the current transaction or subtransaction to be aborted.

  The Perl code is limited to a single string. Longer code can be placed into a module and loaded by the `on_init` string. Examples:

      plperl.on_init = 'require "plperlinit.pl"'
      plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'

  Any modules loaded by `plperl.on_init`, either directly or indirectly, will be available for use by `plperl`. This may create a security risk. To see what modules have been loaded you can use:

      DO 'elog(WARNING, join ", ", sort keys %INC)' language plperl;

  Initialization will happen in the postmaster if the plperl library is included in `shared_preload_libraries` (see shared_preload_libraries), in which case extra consideration should be given to the risk of destabilizing the postmaster.

  This parameter can only be set in the postgresql.conf file or on the server command line.

`plperl.on_plperl_init` (`string`)
`plperl.on_plperlu_init` (`string`)

  These parameters specify Perl code to be executed when the `plperl`, or `plperlu` language is first used in a session. Changes to these parameters after the corresponding language has been used will have no effect. The SPI functions are not available when this code is executed. Only superusers can change these settings. The Perl code in `plperl.on_plperl_init` can only perform trusted operations.

  The effect of setting these parameters is very similar to executing a `DO` command with the Perl code before any other use of the language. The parameters are useful when you want to execute the Perl code automatically on every connection, or when a connection is not interactive. The parameters can be used by non-superusers by having a superuser execute an `ALTER USER ... SET ...` command. For example:

      ALTER USER joe SET plperl.on_plperl_init = '$_SHARED{debug} = 1';

  If the code fails with an error it will abort the initialization and propagate out to the calling query, causing the current transaction or subtransaction to be aborted. Any changes within Perl won't be undone. If the language is used again the initialization will be repeated.

  The difference between these two settings and the `plperl.on_init` setting is that these can be used for settings specific to the trusted or untrusted language variant, such as setting values in the `%_SHARED` variable. By contrast, `plperl.on_init` is more useful for doing things like setting the library search path for Perl or loading Perl modules that don't interact directly with PostgreSQL.

`plperl.use_strict` (`boolean`)

  When set true subsequent compilations of PL/Perl functions have the `strict` pragma enabled. This parameter does not affect functions already compiled in the current session.

## 41.7.2. Limitations and Missing Features

The following features are currently missing from PL/Perl, but they would make welcome contributions.

- PL/Perl functions cannot call each other directly.

- SPI is not yet fully implemented.

- If you are fetching very large data sets using `spi_exec_query`, you should be aware that these will all go into memory. You can avoid this by using `spi_query`/`spi_fetchrow` as illustrated earlier.

  A similar problem occurs if a set-returning function passes a large set of rows back to PostgreSQL via `return`. You can avoid this problem too by instead using `return_next` for each row returned, as shown previously.

- When a session ends normally, not due to a fatal error, any `END` blocks that have been defined are executed. Currently no other actions are performed. Specifically, file handles are not automatically flushed and objects are not automatically destroyed.

Prev | Home | Next
PL/Perl Triggers | Up | PL/Python - Python Procedural Language