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>'
LANGUAGE plpgsql;
</programlisting>
   The function body is simply a string literal so far as <command>CREATE
   FUNCTION</command> is concerned.  It is often helpful to use dollar quoting
   (see <xref linkend="sql-syntax-dollar-quoting"/>) to write the function
   body, rather than the normal single quote syntax.  Without dollar quoting,
   any single quotes or backslashes in the function body must be escaped by
   doubling them.  Almost all the examples in this chapter use dollar-quoted
   literals for their function bodies.
  </para>

  <para>
   <application>PL/pgSQL</application> is a block-structured language.
   The complete text of a function body must be a
   <firstterm>block</firstterm>. A block is defined as:

<synopsis>
<optional> &lt;&lt;<replaceable>label</replaceable>&gt;&gt; </optional>
<optional> DECLARE
    <replaceable>declarations</replaceable> </optional>
BEGIN
    <replaceable>statements</replaceable>
END <optional> <replaceable>label</replaceable> </optional>;
</synopsis>
    </para>

    <para>
     Each declaration and each statement within a block is terminated
     by a semicolon.  A block that appears within another block must
     have a semicolon after <literal>END</literal>, as shown above;
     however the final <literal>END</literal> that
     concludes a function body does not require a semicolon.
    </para>

    <tip>
     <para>
      A common mistake is to write a semicolon immediately after
      <literal>BEGIN</literal>.  This is incorrect and will result in a syntax error.
     </para>
    </tip>

    <para>
     A <replaceable>label</replaceable> is only needed if you want to
     identify the block for use
     in an <literal>EXIT</literal> statement, or to qualify the names of the
     variables declared in the block.  If a label is given after
     <literal>END</literal>, it must match the label at the block's beginning.
    </para>

    <para>
     All key words are case-insensitive.
     Identifiers are implicitly converted to lower case
     unless double-quoted, just as they are in ordinary SQL commands.
    </para>

    <para>
     Comments work the same way in <application>PL/pgSQL</application> code as in
     ordinary SQL.  A double dash (<literal>--</literal>) starts a comment
     that extends to the end of the line. A <literal>/*</literal> starts a
     block comment that extends to the matching occurrence of
     <literal>*/</literal>.  Block comments nest.
    </para>

    <para>
     Any statement in the statement section of a block
     can be a <firstterm>subblock</firstterm>.  Subblocks can be used for
     logical grouping or to localize variables to a small group
     of statements.  Variables declared in a subblock mask any
     similarly-named variables of outer blocks for the duration
     of the subblock; but you can access the outer variables anyway
     if you qualify their names with their block's label. For example:
<programlisting>
CREATE FUNCTION somefunc() RETURNS integer