example, in:
<programlisting>
'(  42)'
</programlisting>
   the whitespace will be ignored if the field type is integer, but not if
   it is text.
  </para>

  <para>
   As shown previously, when writing a composite value you can write double
   quotes around any individual field value.
   You <emphasis>must</emphasis> do so if the field value would otherwise
   confuse the composite-value parser.  In particular, fields containing
   parentheses, commas, double quotes, or backslashes must be double-quoted.
   To put a double quote or backslash in a quoted composite field value,
   precede it with a backslash.  (Also, a pair of double quotes within a
   double-quoted field value is taken to represent a double quote character,
   analogously to the rules for single quotes in SQL literal strings.)
   Alternatively, you can avoid quoting and use backslash-escaping to
   protect all data characters
   that would otherwise be taken as composite syntax.
  </para>

  <para>
   A completely empty field value (no characters at all between the commas
   or parentheses) represents a NULL.  To write a value that is an empty
   string rather than NULL, write <literal>""</literal>.
  </para>

  <para>
   The composite output routine will put double quotes around field values
   if they are empty strings or contain parentheses, commas,
   double quotes, backslashes, or white space.  (Doing so for white space
   is not essential, but aids legibility.)  Double quotes and backslashes
   embedded in field values will be doubled.
  </para>

 <note>
  <para>
   Remember that what you write in an SQL command will first be interpreted
   as a string literal, and then as a composite.  This doubles the number of
   backslashes you need (assuming escape string syntax is used).
   For example, to insert a <type>text</type> field
   containing a double quote and a backslash in a composite
   value, you'd need to write:
<programlisting>
INSERT ... VALUES ('("\"\\")');
</programlisting>
   The string-literal processor removes one level of backslashes, so that
   what arrives at the composite-value parser looks like
   <literal>("\"\\")</literal>.  In turn, the string
   fed to the <type>text</type> data type's input routine
   becomes <literal>"\</literal>.  (If we were working
   with a data type whose input routine also treated backslashes specially,
   <type>bytea</type> for example, we might need as many as eight backslashes
   in the command to get one backslash into the stored composite field.)
   Dollar quoting (see <xref linkend="sql-syntax-dollar-quoting"/>) can be
   used to avoid the need to double backslashes.
  </para>
 </note>

 <tip>
  <para>
   The <literal>ROW</literal> constructor syntax is usually easier to work with
   than the composite-literal syntax when writing composite values in SQL
   commands.
   In <literal>ROW</literal>, individual field values are written the same way
   they would be written when not members of a composite.
  </para>
 </tip>
 </sect2>

</sect1>