it is far safer to create anonymous
    subroutines which you call via a coderef. For more information, see the
    entries for <literal>Variable "%s" will not stay shared</literal> and
    <literal>Variable "%s" is not available</literal> in the
    <citerefentry><refentrytitle>perldiag</refentrytitle></citerefentry> man page, or
    search the Internet for <quote>perl nested named subroutine</quote>.
   </para>
  </note>

  <para>
   The syntax of the <command>CREATE FUNCTION</command> command requires
   the function body to be written as a string constant.  It is usually
   most convenient to use dollar quoting (see <xref
   linkend="sql-syntax-dollar-quoting"/>) for the string constant.
   If you choose to use escape string syntax <literal>E''</literal>,
   you must double any single quote marks (<literal>'</literal>) and backslashes
   (<literal>\</literal>) used in the body of the function
   (see <xref linkend="sql-syntax-strings"/>).
  </para>

  <para>
   Arguments and results are handled as in any other Perl subroutine:
   arguments are passed in <varname>@_</varname>, and a result value
   is returned with <literal>return</literal> or as the last expression
   evaluated in the function.
  </para>

  <para>
   For example, a function returning the greater of two integer values
   could be defined as:

<programlisting>
CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$
    if ($_[0] &gt; $_[1]) { return $_[0]; }
    return $_[1];
$$ LANGUAGE plperl;
</programlisting>
  </para>

  <note>
    <para>
      Arguments will be converted from the database's encoding to UTF-8
      for use inside PL/Perl, and then converted from UTF-8 back to the
      database encoding upon return.
    </para>
  </note>

  <para>
   If an SQL null value<indexterm><primary>null value</primary><secondary
   sortas="PL/Perl">in PL/Perl</secondary></indexterm> is passed to a function,
   the argument value will appear as <quote>undefined</quote> in Perl.  The
   above function definition will not behave very nicely with null
   inputs (in fact, it will act as though they are zeroes).  We could
   add <literal>STRICT</literal> to the function definition to make
   <productname>PostgreSQL</productname> do something more reasonable:
   if a null value is passed, the function will not be called at all,
   but will just return a null result automatically.  Alternatively,
   we could check for undefined inputs in the function body.  For
   example, suppose that we wanted <function>perl_max</function> with
   one null and one nonnull argument to return the nonnull argument,
   rather than a null value:

<programlisting>
CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$
    my ($x, $y) = @_;
    if (not defined $x) {
        return undef if not defined $y;
        return $y;
    }
    return $x if not defined $y;
    return $x if $x &gt; $y;
    return $y;
$$ LANGUAGE plperl;
</programlisting>
   As shown above, to return an SQL null value from a PL/Perl
   function, return an undefined value.  This can be done whether the
   function is strict or not.
  </para>

  <para>
   Anything in a function argument that is not a reference is
   a string, which is in the standard <productname>PostgreSQL</productname>
   external text representation for the relevant data type. In the case of
   ordinary numeric or text types, Perl will just do the right thing and
   the programmer will normally not have to worry about it. However, in
   other cases the argument will need to be converted into a form that is
   more usable in Perl. For example, the <function>decode_bytea</function>
   function can be used to convert an argument of
   type <type>bytea</type> into unescaped binary.
  </para>

  <para>
   Similarly, values passed back to <productname>PostgreSQL</productname>
   must be in the external text representation format. For example, the
   <function>encode_bytea</function> function can be used to
   escape binary data for a return