client/server communication overhead.
    </para>
    <itemizedlist>

     <listitem><para> Extra round trips between
     client and server are eliminated </para></listitem>

     <listitem><para> Intermediate results that the client does not
     need do not have to be marshaled or transferred between server
     and client </para></listitem>

     <listitem><para> Multiple rounds of query
     parsing can be avoided </para></listitem>

    </itemizedlist>
    <para> This can result in a considerable performance increase as
    compared to an application that does not use stored functions.
    </para>

    <para>
     Also, with <application>PL/pgSQL</application> you can use all
     the data types, operators and functions of SQL.
    </para>
  </sect2>

  <sect2 id="plpgsql-args-results">
   <title>Supported Argument and Result Data Types</title>

    <para>
     Functions written in <application>PL/pgSQL</application> can accept
     as arguments any scalar or array data type supported by the server,
     and they can return a result of any of these types.  They can also
     accept or return any composite type (row type) specified by name.
     It is also possible to declare a <application>PL/pgSQL</application>
     function as accepting <type>record</type>, which means that any
     composite type will do as input, or
     as returning <type>record</type>, which means that the result
     is a row type whose columns are determined by specification in the
     calling query, as discussed in <xref linkend="queries-tablefunctions"/>.
    </para>

    <para>
     <application>PL/pgSQL</application> functions can be declared to accept a variable
     number of arguments by using the <literal>VARIADIC</literal> marker.  This
     works exactly the same way as for SQL functions, as discussed in
     <xref linkend="xfunc-sql-variadic-functions"/>.
    </para>

    <para>
     <application>PL/pgSQL</application> functions can also be declared to
     accept and return the polymorphic types described in
     <xref linkend="extend-types-polymorphic"/>, thus allowing the actual data
     types handled by the function to vary from call to call.
     Examples appear in <xref linkend="plpgsql-declaration-parameters"/>.
    </para>

    <para>
     <application>PL/pgSQL</application> functions can also be declared to return
     a <quote>set</quote> (or table) of any data type that can be returned as
     a single instance.  Such a function generates its output by executing
     <command>RETURN NEXT</command> for each desired element of the result
     set, or by using <command>RETURN QUERY</command> to output the result of
     evaluating a query.
    </para>

    <para>
     Finally, a <application>PL/pgSQL</application> function can be declared to return
     <type>void</type> if it has no useful return value.  (Alternatively, it
     could be written as a procedure in that case.)
    </para>

    <para>
     <application>PL/pgSQL</application> functions can also be declared with output
     parameters in place of an explicit specification of the return type.
     This does not add any fundamental capability to the language, but
     it is often convenient, especially for returning multiple values.
     The <literal>RETURNS TABLE</literal> notation can also be used in place
     of <literal>RETURNS SETOF</literal>.
    </para>

    <para>
     Specific examples appear in
     <xref linkend="plpgsql-declaration-parameters"/> and
     <xref linkend="plpgsql-statements-returning"/>.
    </para>
  </sect2>
 </sect1>

 <sect1 id="plpgsql-structure">
  <title>Structure of <application>PL/pgSQL</application></title>

  <para>
   Functions written in <application>PL/pgSQL</application> are defined
   to the server by executing <xref linkend="sql-createfunction"/> commands.
   Such a command would normally look like, say,
<programlisting>
CREATE FUNCTION somefunc(integer, text) RETURNS integer
AS '<replaceable>function body text</replaceable>'