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 between functional notation and field notation
   makes it possible to use functions on composite types to implement
   <quote>computed fields</quote>.
   <indexterm>
    <primary>computed field</primary>
   </indexterm>
   <indexterm>
    <primary>field</primary>
    <secondary>computed</secondary>
   </indexterm>
   An application using the last query above wouldn't need to be directly
   aware that <literal>somefunc</literal> isn't a real column of the table.
  </para>

  <tip>
   <para>
    Because of this behavior, it's unwise to give a function that takes a
    single composite-type argument the same name as any of the fields of
    that composite type.  If there is ambiguity, the field-name
    interpretation will be chosen if field-name syntax is used, while the
    function will be chosen if function-call syntax is used.  However,
    <productname>PostgreSQL</productname> versions before 11 always chose the
    field-name interpretation, unless the syntax of the call required it to
    be a function call.  One 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