could have
      included it, but it would be redundant.
     </para>

     <para>
      To call a function with <literal>OUT</literal> parameters, omit the
      output parameter(s) in the function call:
<programlisting>
SELECT sales_tax(100.00);
</programlisting>
     </para>

     <para>
      Output parameters are most useful when returning multiple values.
      A trivial example is:

<programlisting>
CREATE FUNCTION sum_n_product(x int, y int, OUT sum int, OUT prod int) AS $$
BEGIN
    sum := x + y;
    prod := x * y;
END;
$$ LANGUAGE plpgsql;

SELECT * FROM sum_n_product(2, 4);
 sum | prod
-----+------
   6 |    8
</programlisting>

      As discussed in <xref linkend="xfunc-output-parameters"/>, this
      effectively creates an anonymous record type for the function's
      results.  If a <literal>RETURNS</literal> clause is given, it must say
      <literal>RETURNS record</literal>.
     </para>

     <para>
      This also works with procedures, for example:

<programlisting>
CREATE PROCEDURE sum_n_product(x int, y int, OUT sum int, OUT prod int) AS $$
BEGIN
    sum := x + y;
    prod := x * y;
END;
$$ LANGUAGE plpgsql;
</programlisting>

      In a call to a procedure, all the parameters must be specified.  For
      output parameters, <literal>NULL</literal> may be specified when
      calling the procedure from plain SQL:
<programlisting>
CALL sum_n_product(2, 4, NULL, NULL);
 sum | prod
-----+------
   6 |    8
</programlisting>

      However, when calling a procedure
      from <application>PL/pgSQL</application>, you should instead write a
      variable for any output parameter; the variable will receive the result
      of the call.  See <xref linkend="plpgsql-statements-calling-procedure"/>
      for details.
     </para>

     <para>
      Another way to declare a <application>PL/pgSQL</application> function
      is with <literal>RETURNS TABLE</literal>, for example:

<programlisting>
CREATE FUNCTION extended_sales(p_itemno int)
RETURNS TABLE(quantity int, total numeric) AS $$
BEGIN
    RETURN QUERY SELECT s.quantity, s.quantity * s.price FROM sales AS s
                 WHERE s.itemno = p_itemno;
END;
$$ LANGUAGE plpgsql;
</programlisting>

      This is exactly equivalent to declaring one or more <literal>OUT</literal>
      parameters and specifying <literal>RETURNS SETOF
      <replaceable>sometype</replaceable></literal>.
     </para>

     <para>
      When the return type of a <application>PL/pgSQL</application> function
      is declared as a polymorphic type (see
      <xref linkend="extend-types-polymorphic"/>), a special
      parameter <literal>$0</literal> is created.  Its data type is the actual
      return type of the function, as deduced from the actual input types.
      This allows the function to access its actual return type
      as shown in <xref linkend="plpgsql-declaration-type"/>.
      <literal>$0</literal> is initialized to null and can be modified by
      the function, so it can be used to hold the return value if desired,
      though that is not required.  <literal>$0</literal> can also be
      given an alias.  For example, this function works on any data type
      that has a <literal>+</literal> operator:

<programlisting>
CREATE FUNCTION add_three_values(v1 anyelement, v2 anyelement, v3 anyelement)
RETURNS anyelement AS $$
DECLARE
    result ALIAS FOR $0;
BEGIN
    result := v1 + v2 + v3;
    RETURN result;
END;
$$ LANGUAGE plpgsql;
</programlisting>
     </para>

     <para>
      The same effect can be obtained by declaring one or more output parameters as
      polymorphic types.  In this case the
      special <literal>$0</literal> parameter is not used; the output
      parameters themselves serve the same purpose.  For example:

<programlisting>
CREATE FUNCTION add_three_values(v1 anyelement, v2 anyelement, v3 anyelement,
                                 OUT sum anyelement)
AS $$
BEGIN
    sum := v1 + v2 + v3;
END;
$$ LANGUAGE plpgsql;
</programlisting>
     </para>