|The PostgreSQL 9.0 Reference Manual - Volume 2 - Programming Guide
by The PostgreSQL Global Development Group
Paperback (6"x9"), 478 pages
RRP £14.95 ($19.95)
Sales of this book support the PostgreSQL project! Get a printed copy>>>
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
Specifies Perl code to be executed when a Perl interpreter is first
initialized, before it is specialized for use by
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
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, in which case extra consideration should be given to the risk of destabilizing the postmaster. The principal reason for making use of this feature is that Perl modules loaded by
plperl.on_initneed be loaded only at postmaster start, and will be instantly available without loading overhead in individual database sessions. However, keep in mind that the overhead is avoided only for the first Perl interpreter used by a database session--either PL/PerlU, or PL/Perl for the first SQL role that calls a PL/Perl function. Any additional Perl interpreters created in a database session will have to execute
plperl.on_initafresh. Also, on Windows there will be no savings whatsoever from preloading, since the Perl interpreter created in the postmaster process does not propagate to child processes. This parameter can only be set in the postgresql.conf file or on the server command line.
These parameters specify Perl code to be executed when a Perl
interpreter is specialized for
plperlurespectively. This will happen when a PL/Perl or PL/PerlU function is first executed in a database session, or when an additional interpreter has to be created because the other language is called or a PL/Perl function is called by a new SQL role. This follows any initialization done by
plperl.on_init. The SPI functions are not available when this code is executed. The Perl code in
plperl.on_plperl_initis executed after “locking down” the interpreter, and thus it can only perform trusted operations. 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 actions already done within Perl won't be undone; however, that interpreter won't be used again. If the language is used again the initialization will be attempted again within a fresh Perl interpreter. Only superusers can change these settings. Although these settings can be changed within a session, such changes will not affect Perl interpreters that have already been used to execute functions.
When set true subsequent compilations of PL/Perl functions will have
strictpragma enabled. This parameter does not affect functions already compiled in the current session.
|ISBN 9781906966065||The PostgreSQL 9.0 Reference Manual - Volume 2 - Programming Guide||See the print edition|