linkend="install-short"> for more information.) Users of

you must double the single quote marks (<literal>'</>) and backslashes

The <varname>%_SHARED</varname> variable and other global state within

the language are public data, available to all PL/Perl functions within a

session. Use with care, especially in situations that involve use of

multiple roles or <literal>SECURITY DEFINER</> functions.

<para>

For security reasons, to stop a leak of privileged operations from

<application>PL/PerlU</> to <application>PL/Perl</>, these two languages

have to run in separate instances of the Perl interpreter. If your

Perl installation has been appropriately compiled, this is not a problem.

However, not all installations are compiled with the requisite flags.

If <productname>PostgreSQL</> detects that this is the case then it will

not start a second interpreter, but instead create an error. In

consequence, in such an installation, you cannot use both

<application>PL/PerlU</> and <application>PL/Perl</> in the same backend

process. The remedy for this is to obtain a Perl installation configured

with the appropriate flags, namely either <literal>usemultiplicity</>

or <literal>useithreads</>. <literal>usemultiplicity</> is preferred

unless you actually need to use threads. For more details, see the

<citerefentry><refentrytitle>perlembed</></citerefentry> man page.

</para>

Specifies Perl code to be executed when a Perl interpreter is first initialized

and before it is specialized for use by <literal>plperl</> or <literal>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.

Initialization will happen in the postmaster if the plperl library is included

in <literal>shared_preload_libraries</> (see <xref linkend="guc-shared-preload-libraries">),

in which case extra consideration should be given to the risk of destabilizing the postmaster.

These parameters specify Perl code to be executed when the

<literal>plperl</>, or <literal>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 <literal>plperl.on_plperl_init</> can only perform trusted operations.

</para>

<para>

The effect of setting these parameters is very similar to executing a

<literal>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 <literal>ALTER USER ... SET ...</> command.

For example:

<programlisting>

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

</programlisting>

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

<literal>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 <varname>%_SHARED</> variable. By contrast,

<literal>plperl.on_init</> is more useful for doing things like

setting the library search path for <productname>Perl</> or

loading Perl modules that don't interact directly with

<productname>PostgreSQL</>.

When set true subsequent compilations of PL/Perl functions have the <literal>strict</> pragma enabled.

This parameter does not affect functions already compiled in the current session.

This is easily done since

all PL/Tcl functions executed in one session share the same

safe Tcl interpreter. So, any global Tcl variable is accessible to

all PL/Tcl function calls and will persist for the duration of the

SQL session. (Note that <application>PL/TclU</> functions likewise share

global data, but they are in a different Tcl interpreter and cannot

communicate with PL/Tcl functions.)

multiple functions.

happens separately for PL/Tcl and PL/TclU, if both are used,

because separate interpreters are used for the two languages.)