Home Explore Blog CI



postgresql

4th chunk of `doc/src/sgml/xplang.sgml`
03af1d99ae29824185433a692ab2e1c101c0cbad4bc34fb90000000100000c42
 safely create functions and
      procedures. Since PL functions are executed inside the database
      server, the <literal>TRUSTED</literal> flag should only be given
      for languages that do not allow access to database server
      internals or the file system. The languages
      <application>PL/pgSQL</application>,
      <application>PL/Tcl</application>, and
      <application>PL/Perl</application>
      are considered trusted; the languages
      <application>PL/TclU</application>,
      <application>PL/PerlU</application>, and
      <application>PL/PythonU</application>
      are designed to provide unlimited functionality and should
      <emphasis>not</emphasis> be marked trusted.
     </para>
    </step>
   </procedure>

   <para>
    <xref linkend="xplang-install-example"/> shows how the manual
    installation procedure would work with the language
    <application>PL/Perl</application>.
   </para>

   <example id="xplang-install-example">
    <title>Manual Installation of <application>PL/Perl</application></title>

     <para>
      The following command tells the database server where to find the
      shared object for the <application>PL/Perl</application> language's call
      handler function:

<programlisting>
CREATE FUNCTION plperl_call_handler() RETURNS language_handler AS
    '$libdir/plperl' LANGUAGE C;
</programlisting>
     </para>

     <para>
      <application>PL/Perl</application> has an inline handler function
      and a validator function, so we declare those too:

<programlisting>
CREATE FUNCTION plperl_inline_handler(internal) RETURNS void AS
    '$libdir/plperl' LANGUAGE C STRICT;

CREATE FUNCTION plperl_validator(oid) RETURNS void AS
    '$libdir/plperl' LANGUAGE C STRICT;
</programlisting>
     </para>

     <para>
      The command:
<programlisting>
CREATE TRUSTED LANGUAGE plperl
    HANDLER plperl_call_handler
    INLINE plperl_inline_handler
    VALIDATOR plperl_validator;
</programlisting>
      then defines that the previously declared functions
      should be invoked for functions and procedures where the
      language attribute is <literal>plperl</literal>.
     </para>
  </example>

   <para>
    In a default <productname>PostgreSQL</productname> installation,
    the handler for the <application>PL/pgSQL</application> language
    is built and installed into the <quote>library</quote>
    directory; furthermore, the <application>PL/pgSQL</application> language
    itself is installed in all databases.
    If <application>Tcl</application> support is configured in, the handlers for
    <application>PL/Tcl</application> and <application>PL/TclU</application> are built and installed
    in the library directory, but the language itself is not installed in any
    database by default.
    Likewise, the <application>PL/Perl</application> and <application>PL/PerlU</application>
    handlers are built and installed if Perl support is configured, and the
    <application>PL/PythonU</application> handler is installed if Python support is
    configured, but these languages are not installed by default.
   </para>

  </sect1>

</chapter>

Title: Manual Installation of PL/Perl in PostgreSQL
Summary
This section provides a detailed example of how to manually install the PL/Perl procedural language in PostgreSQL. It outlines the SQL commands needed to create the necessary functions: the call handler, inline handler, and validator function. The example shows how to declare these functions using CREATE FUNCTION statements, specifying their locations in the shared library. Finally, it demonstrates how to create the trusted language 'plperl' using the CREATE TRUSTED LANGUAGE command, which associates the previously declared functions with the language. The text also briefly mentions the default installation status of various procedural languages in PostgreSQL, including PL/pgSQL, PL/Tcl, PL/TclU, PL/Perl, PL/PerlU, and PL/PythonU.