<structname>some_table</structname>.)
   </para>
  </tip>

  <para>
   The <replaceable>composite_value</replaceable><literal>.*</literal> syntax results in
   column expansion of this kind when it appears at the top level of
   a <link linkend="queries-select-lists"><command>SELECT</command> output
   list</link>, a <link linkend="dml-returning"><literal>RETURNING</literal>
   list</link> in <command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>/<command>MERGE</command>,
   a <link linkend="queries-values"><literal>VALUES</literal> clause</link>, or
   a <link linkend="sql-syntax-row-constructors">row constructor</link>.
   In all other contexts (including when nested inside one of those
   constructs), attaching <literal>.*</literal> to a composite value does not
   change the value, since it means <quote>all columns</quote> and so the
   same composite value is produced again.  For example,
   if <function>somefunc()</function> accepts a composite-valued argument,
   these queries are the same:

<programlisting>
SELECT somefunc(c.*) FROM inventory_item c;
SELECT somefunc(c) FROM inventory_item c;
</programlisting>

   In both cases, the current row of <structname>inventory_item</structname> is
   passed to the function as a single composite-valued argument.
   Even though <literal>.*</literal> does nothing in such cases, using it is good
   style, since it makes clear that a composite value is intended.  In
   particular, the parser will consider <literal>c</literal> in <literal>c.*</literal> to
   refer to a table name or alias, not to a column name, so that there is
   no ambiguity; whereas without <literal>.*</literal>, it is not clear
   whether <literal>c</literal> means a table name or a column name, and in fact
   the column-name interpretation will be preferred if there is a column
   named <literal>c</literal>.
  </para>

  <para>
   Another example demonstrating these concepts is that all these queries
   mean the same thing:
<programlisting>
SELECT * FROM inventory_item c ORDER BY c;
SELECT * FROM inventory_item c ORDER BY c.*;
SELECT * FROM inventory_item c ORDER BY ROW(c.*);
</programlisting>
   All of these <literal>ORDER BY</literal> clauses specify the row's composite
   value, resulting in sorting the rows according to the rules described
   in <xref linkend="composite-type-comparison"/>.  However,
   if <structname>inventory_item</structname> contained a column
   named <structfield>c</structfield>, the first case would be different from the
   others, as it would mean to sort by that column only.  Given the column
   names previously shown, these queries are also equivalent to those above:
<programlisting>
SELECT * FROM inventory_item c ORDER BY ROW(c.name, c.supplier_id, c.price);
SELECT * FROM inventory_item c ORDER BY (c.name, c.supplier_id, c.price);
</programlisting>
   (The last case uses a row constructor with the key word <literal>ROW</literal>
   omitted.)
  </para>

  <para>
   Another special syntactical behavior associated with composite values is
   that we can use <firstterm>functional notation</firstterm> for extracting a field
   of a composite value.  The simple way to explain this is that
   the notations <literal><replaceable>field</replaceable>(<replaceable>table</replaceable>)</literal>
   and <literal><replaceable>table</replaceable>.<replaceable>field</replaceable></literal>
   are interchangeable.  For example, these queries are equivalent:

<programlisting>
SELECT c.name FROM inventory_item c WHERE c.price &gt; 1000;
SELECT name(c) FROM inventory_item c WHERE price(c) &gt; 1000;
</programlisting>

   Moreover, if we have a function that accepts a single argument of a
   composite type, we can call it with either notation.  These queries are
   all equivalent:

<programlisting>
SELECT somefunc(c) FROM inventory_item c;
SELECT somefunc(c.*) FROM inventory_item c;
SELECT c.somefunc FROM inventory_item c;
</programlisting>
  </para>

  <para>
   This equivalence