1#@!#!123s

: / usr / share / doc / postgresql-9.2.24 / html /
Filename : plperl-under-the-hood.html
back
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>PL/Perl Under the Hood</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PL/Perl - Perl Procedural Language"
HREF="plperl.html"><LINK
REL="PREVIOUS"
TITLE="PL/Perl Triggers"
HREF="plperl-triggers.html"><LINK
REL="NEXT"
TITLE="PL/Python - Python Procedural Language"
HREF="plpython.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="PL/Perl Triggers"
HREF="plperl-triggers.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plperl.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 41. PL/Perl - Perl Procedural Language</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="PL/Python - Python Procedural Language"
HREF="plpython.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PLPERL-UNDER-THE-HOOD"
>41.7. PL/Perl Under the Hood</A
></H1
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPERL-CONFIG"
>41.7.1. Configuration</A
></H2
><P
>  This section lists configuration parameters that affect <SPAN
CLASS="APPLICATION"
>PL/Perl</SPAN
>.
  </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-PLPERL-ON-INIT"
></A
><TT
CLASS="VARNAME"
>plperl.on_init</TT
> (<TT
CLASS="TYPE"
>string</TT
>)</DT
><DD
><P
>        Specifies Perl code to be executed when a Perl interpreter is first
        initialized, before it is specialized for use by <TT
CLASS="LITERAL"
>plperl</TT
> or
        <TT
CLASS="LITERAL"
>plperlu</TT
>.
        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.
       </P
><P
>       The Perl code is limited to a single string. Longer code can be placed
       into a module and loaded by the <TT
CLASS="LITERAL"
>on_init</TT
> string.
       Examples:
</P><PRE
CLASS="PROGRAMLISTING"
>plperl.on_init = 'require "plperlinit.pl"'
plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'</PRE
><P>
       </P
><P
>       Any modules loaded by <TT
CLASS="LITERAL"
>plperl.on_init</TT
>, either directly or
       indirectly, will be available for use by <TT
CLASS="LITERAL"
>plperl</TT
>.  This may
       create a security risk. To see what modules have been loaded you can use:
</P><PRE
CLASS="PROGRAMLISTING"
>DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;</PRE
><P>
       </P
><P
>        Initialization will happen in the postmaster if the plperl library is
        included in <A
HREF="runtime-config-resource.html#GUC-SHARED-PRELOAD-LIBRARIES"
>shared_preload_libraries</A
>, 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 <TT
CLASS="LITERAL"
>plperl.on_init</TT
> need 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 &mdash; 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 <TT
CLASS="LITERAL"
>plperl.on_init</TT
> afresh.  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.
       </P
><P
>       This parameter can only be set in the <TT
CLASS="FILENAME"
>postgresql.conf</TT
> file or on the server command line.
       </P
></DD
><DT
><A
NAME="GUC-PLPERL-ON-PLPERL-INIT"
></A
><TT
CLASS="VARNAME"
>plperl.on_plperl_init</TT
> (<TT
CLASS="TYPE"
>string</TT
>)<BR><TT
CLASS="VARNAME"
>plperl.on_plperlu_init</TT
> (<TT
CLASS="TYPE"
>string</TT
>)</DT
><DD
><P
>        These parameters specify Perl code to be executed when a Perl
        interpreter is specialized for <TT
CLASS="LITERAL"
>plperl</TT
> or
        <TT
CLASS="LITERAL"
>plperlu</TT
> respectively.  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 <TT
CLASS="LITERAL"
>plperl.on_init</TT
>.
        The SPI functions are not available when this code is executed.
        The Perl code in <TT
CLASS="LITERAL"
>plperl.on_plperl_init</TT
> is executed after
        <SPAN
CLASS="QUOTE"
>"locking down"</SPAN
> the interpreter, and thus it can only perform
        trusted operations.
       </P
><P
>        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.
       </P
><P
>        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.
       </P
></DD
><DT
><A
NAME="GUC-PLPERL-USE-STRICT"
></A
><TT
CLASS="VARNAME"
>plperl.use_strict</TT
> (<TT
CLASS="TYPE"
>boolean</TT
>)</DT
><DD
><P
>        When set true subsequent compilations of PL/Perl functions will have
        the <TT
CLASS="LITERAL"
>strict</TT
> pragma enabled.  This parameter does not affect
        functions already compiled in the current session.
       </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPERL-MISSING"
>41.7.2. Limitations and Missing Features</A
></H2
><P
>   The following features are currently missing from PL/Perl, but they
   would make welcome contributions.

   <P
></P
></P><UL
><LI
><P
>      PL/Perl functions cannot call each other directly.
     </P
></LI
><LI
><P
>      SPI is not yet fully implemented.
     </P
></LI
><LI
><P
>      If you are fetching very large data sets using
      <TT
CLASS="LITERAL"
>spi_exec_query</TT
>, you should be aware that
      these will all go into memory.  You can avoid this by using
      <TT
CLASS="LITERAL"
>spi_query</TT
>/<TT
CLASS="LITERAL"
>spi_fetchrow</TT
> as
      illustrated earlier.
     </P
><P
>        A similar problem occurs if a set-returning function passes a
        large set of rows back to PostgreSQL via <TT
CLASS="LITERAL"
>return</TT
>. You
        can avoid this problem too by instead using
        <TT
CLASS="LITERAL"
>return_next</TT
> for each row returned, as shown
        previously.
     </P
></LI
><LI
><P
>        When a session ends normally, not due to a fatal error, any
        <TT
CLASS="LITERAL"
>END</TT
> 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.
      </P
></LI
></UL
><P>
  </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="plperl-triggers.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="plpython.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>PL/Perl Triggers</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="plperl.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>PL/Python - Python Procedural Language</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>