syntax rules.
  You must write it like this:

<programlisting>
SELECT (item).name FROM on_hand WHERE (item).price &gt; 9.99;
</programlisting>

  or if you need to use the table name as well (for instance in a multitable
  query), like this:

<programlisting>
SELECT (on_hand.item).name FROM on_hand WHERE (on_hand.item).price &gt; 9.99;
</programlisting>

  Now the parenthesized object is correctly interpreted as a reference to
  the <literal>item</literal> column, and then the subfield can be selected from it.
 </para>

 <para>
  Similar syntactic issues apply whenever you select a field from a composite
  value.  For instance, to select just one field from the result of a function
  that returns a composite value, you'd need to write something like:

<programlisting>
SELECT (my_func(...)).field FROM ...
</programlisting>

  Without the extra parentheses, this will generate a syntax error.
 </para>

 <para>
  The special field name <literal>*</literal> means <quote>all fields</quote>, as
  further explained in <xref linkend="rowtypes-usage"/>.
 </para>
 </sect2>

 <sect2 id="rowtypes-modifying">
  <title>Modifying Composite Types</title>

 <para>
  Here are some examples of the proper syntax for inserting and updating
  composite columns.
  First, inserting or updating a whole column:

<programlisting>
INSERT INTO mytab (complex_col) VALUES((1.1,2.2));

UPDATE mytab SET complex_col = ROW(1.1,2.2) WHERE ...;
</programlisting>

  The first example omits <literal>ROW</literal>, the second uses it; we
  could have done it either way.
 </para>

 <para>
  We can update an individual subfield of a composite column:

<programlisting>
UPDATE mytab SET complex_col.r = (complex_col).r + 1 WHERE ...;
</programlisting>

  Notice here that we don't need to (and indeed cannot)
  put parentheses around the column name appearing just after
  <literal>SET</literal>, but we do need parentheses when referencing the same
  column in the expression to the right of the equal sign.
 </para>

 <para>
  And we can specify subfields as targets for <command>INSERT</command>, too:

<programlisting>
INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
</programlisting>

  Had we not supplied values for all the subfields of the column, the
  remaining subfields would have been filled with null values.
 </para>
 </sect2>

 <sect2 id="rowtypes-usage">
  <title>Using Composite Types in Queries</title>

  <para>
   There are various special syntax rules and behaviors associated with
   composite types in queries.  These rules provide useful shortcuts,
   but can be confusing if you don't know the logic behind them.
  </para>

  <para>
   In <productname>PostgreSQL</productname>, a reference to a table name (or alias)
   in a query is effectively a reference to the composite value of the
   table's current row.  For example, if we had a table
   <structname>inventory_item</structname> as shown
   <link linkend="rowtypes-declaring">above</link>, we could write:
<programlisting>
SELECT c FROM inventory_item c;
</programlisting>
   This query produces a single composite-valued column, so we might get
   output like:
<programlisting>
           c
------------------------
 ("fuzzy dice",42,1.99)
(1 row)
</programlisting>
   Note however that simple names are matched to column names before table
   names, so this example works only because there is no column
   named <structfield>c</structfield> in the query's tables.
  </para>

  <para>
   The ordinary qualified-column-name
   syntax <replaceable>table_name</replaceable><literal>.</literal><replaceable>column_name</replaceable>
   can be understood as applying <link linkend="field-selection">field
   selection</link> to the composite value of the table's current row.
   (For efficiency reasons, it's not actually implemented that way.)
  </para>

  <para>
   When we write
<programlisting>
SELECT c.* FROM inventory_item c;
</programlisting>
   then, according to the SQL standard, we should get the contents