parameter.
    For example:

<programlisting>
mytable.mycolumn
$1.somecolumn
(rowfunction(a,b)).col3
</programlisting>

    (Thus, a qualified column reference is actually just a special case
    of the field selection syntax.)  An important special case is
    extracting a field from a table column that is of a composite type:

<programlisting>
(compositecol).somefield
(mytable.compositecol).somefield
</programlisting>

    The parentheses are required here to show that
    <structfield>compositecol</structfield> is a column name not a table name,
    or that <structname>mytable</structname> is a table name not a schema name
    in the second case.
   </para>

   <para>
    You can ask for all fields of a composite value by
    writing <literal>.*</literal>:
<programlisting>
(compositecol).*
</programlisting>
    This notation behaves differently depending on context;
    see <xref linkend="rowtypes-usage"/> for details.
   </para>
  </sect2>

  <sect2 id="sql-expressions-operator-calls">
   <title>Operator Invocations</title>

   <indexterm>
    <primary>operator</primary>
    <secondary>invocation</secondary>
   </indexterm>

   <para>
    There are two possible syntaxes for an operator invocation:
    <simplelist>
     <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable> (binary infix operator)</member>
     <member><replaceable>operator</replaceable> <replaceable>expression</replaceable> (unary prefix operator)</member>
    </simplelist>
    where the <replaceable>operator</replaceable> token follows the syntax
    rules of <xref linkend="sql-syntax-operators"/>, or is one of the
    key words <token>AND</token>, <token>OR</token>, and
    <token>NOT</token>, or is a qualified operator name in the form:
<synopsis>
<literal>OPERATOR(</literal><replaceable>schema</replaceable><literal>.</literal><replaceable>operatorname</replaceable><literal>)</literal>
</synopsis>
    Which particular operators exist and whether
    they are unary or binary depends on what operators have been
    defined by the system or the user.  <xref linkend="functions"/>
    describes the built-in operators.
   </para>
  </sect2>

  <sect2 id="sql-expressions-function-calls">
   <title>Function Calls</title>

   <indexterm>
    <primary>function</primary>
    <secondary>invocation</secondary>
   </indexterm>

   <para>
    The syntax for a function call is the name of a function
    (possibly qualified with a schema name), followed by its argument list
    enclosed in parentheses:

<synopsis>
<replaceable>function_name</replaceable> (<optional><replaceable>expression</replaceable> <optional>, <replaceable>expression</replaceable> ... </optional></optional> )
</synopsis>
   </para>

   <para>
    For example, the following computes the square root of 2:
<programlisting>
sqrt(2)
</programlisting>
   </para>

   <para>
    The list of built-in functions is in <xref linkend="functions"/>.
    Other functions can be added by the user.
   </para>

   <para>
    When issuing queries in a database where some users mistrust other users,
    observe security precautions from <xref linkend="typeconv-func"/> when
    writing function calls.
   </para>

   <para>
    The arguments can optionally have names attached.
    See <xref linkend="sql-syntax-calling-funcs"/> for details.
   </para>

   <note>
    <para>
     A function that takes a single argument of composite type can
     optionally be called using field-selection syntax, and conversely
     field selection can be written in functional style.  That is, the
     notations <literal>col(table)</literal> and <literal>table.col</literal> are
     interchangeable.  This behavior is not SQL-standard but is provided
     in <productname>PostgreSQL</productname> because it allows use of functions to
     emulate <quote>computed fields</quote>.  For more information see
     <xref linkend="rowtypes-usage"/>.
    </para>
   </note>
  </sect2>

  <sect2