point '(2,2)' AS cubicle;
$$ LANGUAGE SQL;
</programlisting>

     In this example we have specified each of  the  attributes
     with  a  constant value, but any computation
     could have been substituted for these constants.
    </para>

    <para>
     Note two important things about defining the function:

     <itemizedlist>
      <listitem>
       <para>
        The select list order in the query must be exactly the same as
        that in which the columns appear in the composite type.
        (Naming the columns, as we did above,
        is irrelevant to the system.)
       </para>
      </listitem>
      <listitem>
       <para>
        We must ensure each expression's type can be cast to that of
        the corresponding column of the composite type.
        Otherwise we'll get errors like this:
<screen>
<computeroutput>
ERROR:  return type mismatch in function declared to return emp
DETAIL:  Final statement returns text instead of point at column 4.
</computeroutput>
</screen>
        As with the base-type case, the system will not insert explicit
        casts automatically, only implicit or assignment casts.
       </para>
      </listitem>
     </itemizedlist>
    </para>

    <para>
     A different way to define the same function is:

<programlisting>
CREATE FUNCTION new_emp() RETURNS emp AS $$
    SELECT ROW('None', 1000.0, 25, '(2,2)')::emp;
$$ LANGUAGE SQL;
</programlisting>

     Here we wrote a <command>SELECT</command> that returns just a single
     column of the correct composite type.  This isn't really better
     in this situation, but it is a handy alternative in some cases
     &mdash; for example, if we need to compute the result by calling
     another function that returns the desired composite value.
     Another example is that if we are trying to write a function that
     returns a domain over composite, rather than a plain composite type,
     it is always necessary to write it as returning a single column,
     since there is no way to cause a coercion of the whole row result.
    </para>

    <para>
     We could call this function directly either by using it in
     a value expression:

<screen>
SELECT new_emp();

         new_emp
--------------------------
 (None,1000.0,25,"(2,2)")
</screen>

     or by calling it as a table function:

<screen>
SELECT * FROM new_emp();

 name | salary | age | cubicle
------+--------+-----+---------
 None | 1000.0 |  25 | (2,2)
</screen>

     The second way is described more fully in <xref
     linkend="xfunc-sql-table-functions"/>.
    </para>

    <para>
     When you use a function that returns a composite type,
     you might want only one field (attribute) from its result.
     You can do that with syntax like this:

<screen>
SELECT (new_emp()).name;

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

     The extra parentheses are needed to keep the parser from getting
     confused.  If you try to do it without them, you get something like this:

<screen>
SELECT new_emp().name;
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