ERROR:  syntax error at or near "."
LINE 1: SELECT new_emp().name;
                        ^
</screen>
    </para>

    <para>
     Another option is to use functional notation for extracting an attribute:

<screen>
SELECT name(new_emp());

 name
------
 None
</screen>

     As explained in <xref linkend="rowtypes-usage"/>, the field notation and
     functional notation are equivalent.
    </para>

    <para>
     Another way to use a function returning a composite type is to pass the
     result to another function that accepts the correct row type as input:

<screen>
CREATE FUNCTION getname(emp) RETURNS text AS $$
    SELECT $1.name;
$$ LANGUAGE SQL;

SELECT getname(new_emp());
 getname
---------
 None
(1 row)
</screen>
    </para>
   </sect2>

   <sect2 id="xfunc-output-parameters">
    <title><acronym>SQL</acronym> Functions with Output Parameters</title>

   <indexterm>
    <primary>function</primary>
    <secondary>output parameter</secondary>
   </indexterm>

    <para>
     An alternative way of describing a function's results is to define it
     with <firstterm>output parameters</firstterm>, as in this example:

<screen>
CREATE FUNCTION add_em (IN x int, IN y int, OUT sum int)
AS 'SELECT x + y'
LANGUAGE SQL;

SELECT add_em(3,7);
 add_em
--------
     10
(1 row)
</screen>

     This is not essentially different from the version of <literal>add_em</literal>
     shown in <xref linkend="xfunc-sql-base-functions"/>.  The real value of
     output parameters is that they provide a convenient way of defining
     functions that return several columns.  For example,

<screen>
CREATE FUNCTION sum_n_product (x int, y int, OUT sum int, OUT product int)
AS 'SELECT x + y, x * y'
LANGUAGE SQL;

 SELECT * FROM sum_n_product(11,42);
 sum | product
-----+---------
  53 |     462
(1 row)
</screen>

     What has essentially happened here is that we have created an anonymous
     composite type for the result of the function.  The above example has
     the same end result as

<screen>
CREATE TYPE sum_prod AS (sum int, product int);

CREATE FUNCTION sum_n_product (int, int) RETURNS sum_prod
AS 'SELECT $1 + $2, $1 * $2'
LANGUAGE SQL;
</screen>

     but not having to bother with the separate composite type definition
     is often handy.  Notice that the names attached to the output parameters
     are not just decoration, but determine the column names of the anonymous
     composite type.  (If you omit a name for an output parameter, the
     system will choose a name on its own.)
    </para>

    <para>
     Notice that output parameters are not included in the calling argument
     list when invoking such a function from SQL.  This is because
     <productname>PostgreSQL</productname> considers only the input
     parameters to define the function's calling signature.  That means
     also that only the input parameters matter when referencing the function
     for purposes such as dropping it.  We could drop the above function
     with either of

<screen>
DROP FUNCTION sum_n_product (x int, y int, OUT sum int, OUT product int);
DROP FUNCTION sum_n_product (int, int);
</screen>
    </para>

    <para>
     Parameters can be marked as <literal>IN</literal> (the default),
     <literal>OUT</literal>, <literal>INOUT</literal>, or <literal>VARIADIC</literal>.
     An <literal>INOUT</literal>
     parameter serves as both an input parameter (part of the calling
     argument list) and an output parameter (part of the result record type).
     <literal>VARIADIC</literal> parameters are input parameters, but are treated
     specially as described below.
    </para>
   </sect2>

   <sect2 id="xfunc-output-parameters-proc">
    <title><acronym>SQL</acronym> Procedures with Output Parameters</title>

    <indexterm>
     <primary>procedures</primary>
     <secondary>output parameter</secondary>
    </indexterm>

    <para>
     Output parameters are also supported in procedures, but they work a bit
     differently from functions.  In <command>CALL</command>