way to force the function interpretation in
older versions is to schema-qualify the function name, that is, write
<literal><replaceable>schema</replaceable>.<replaceable>func</replaceable>(<replaceable>compositevalue</replaceable>)</literal>.
</para>
</tip>
</sect2>
<sect2 id="rowtypes-io-syntax">
<title>Composite Type Input and Output Syntax</title>
<para>
The external text representation of a composite value consists of items that
are interpreted according to the I/O conversion rules for the individual
field types, plus decoration that indicates the composite structure.
The decoration consists of parentheses (<literal>(</literal> and <literal>)</literal>)
around the whole value, plus commas (<literal>,</literal>) between adjacent
items. Whitespace outside the parentheses is ignored, but within the
parentheses it is considered part of the field value, and might or might not be
significant depending on the input conversion rules for the field data type.
For 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