<indexterm>
   <primary>composite type</primary>
   <secondary>constant</secondary>
  </indexterm>

  <para>
   To write a composite value as a literal constant, enclose the field
   values within parentheses and separate them by commas.  You can put double
   quotes around any field value, and must do so if it contains commas or
   parentheses.  (More details appear <link
   linkend="rowtypes-io-syntax">below</link>.)  Thus, the general format of
   a composite constant is the following:
<synopsis>
'( <replaceable>val1</replaceable> , <replaceable>val2</replaceable> , ... )'
</synopsis>
   An example is:
<programlisting>
'("fuzzy dice",42,1.99)'
</programlisting>
   which would be a valid value of the <literal>inventory_item</literal> type
   defined above.  To make a field be NULL, write no characters at all
   in its position in the list.  For example, this constant specifies
   a NULL third field:
<programlisting>
'("fuzzy dice",42,)'
</programlisting>
   If you want an empty string rather than NULL, write double quotes:
<programlisting>
'("",42,)'
</programlisting>
   Here the first field is a non-NULL empty string, the third is NULL.
  </para>

  <para>
   (These constants are actually only a special case of
   the generic type constants discussed in <xref
   linkend="sql-syntax-constants-generic"/>.  The constant is initially
   treated as a string and passed to the composite-type input conversion
   routine.  An explicit type specification might be necessary to tell
   which type to convert the constant to.)
  </para>

 <para>
  The <literal>ROW</literal> expression syntax can also be used to
  construct composite values.  In most cases this is considerably
  simpler to use than the string-literal syntax since you don't have
  to worry about multiple layers of quoting.  We already used this
  method above:
<programlisting>
ROW('fuzzy dice', 42, 1.99)
ROW('', 42, NULL)
</programlisting>
  The ROW keyword is actually optional as long as you have more than one
  field in the expression, so these can be simplified to:
<programlisting>
('fuzzy dice', 42, 1.99)
('', 42, NULL)
</programlisting>
  The <literal>ROW</literal> expression syntax is discussed in more detail in <xref
  linkend="sql-syntax-row-constructors"/>.
 </para>
 </sect2>

 <sect2 id="rowtypes-accessing">
  <title>Accessing Composite Types</title>

 <para>
  To access a field of a composite column, one writes a dot and the field
  name, much like selecting a field from a table name.  In fact, it's so
  much like selecting from a table name that you often have to use parentheses
  to keep from confusing the parser.  For example, you might try to select
  some subfields from our <literal>on_hand</literal> example table with something
  like:

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

  This will not work since the name <literal>item</literal> is taken to be a table
  name, not a column name of <literal>on_hand</literal>, per SQL 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