precedence rules also apply to user-defined
    operators that have the same names as the built-in operators
    mentioned above.  For example, if you define a
    <quote>+</quote> operator for some custom data type it will have
    the same precedence as the built-in <quote>+</quote> operator, no
    matter what yours does.
   </para>

   <para>
    When a schema-qualified operator name is used in the
    <literal>OPERATOR</literal> syntax, as for example in:
<programlisting>
SELECT 3 OPERATOR(pg_catalog.+) 4;
</programlisting>
    the <literal>OPERATOR</literal> construct is taken to have the default precedence
    shown in <xref linkend="sql-precedence-table"/> for
    <quote>any other operator</quote>.  This is true no matter
    which specific operator appears inside <literal>OPERATOR()</literal>.
   </para>

   <note>
    <para>
     <productname>PostgreSQL</productname> versions before 9.5 used slightly different
     operator precedence rules.  In particular, <token>&lt;=</token>
     <token>&gt;=</token> and <token>&lt;&gt;</token> used to be treated as
     generic operators; <literal>IS</literal> tests used to have higher priority;
     and <literal>NOT BETWEEN</literal> and related constructs acted inconsistently,
     being taken in some cases as having the precedence of <literal>NOT</literal>
     rather than <literal>BETWEEN</literal>.  These rules were changed for better
     compliance with the SQL standard and to reduce confusion from
     inconsistent treatment of logically equivalent constructs.  In most
     cases, these changes will result in no behavioral change, or perhaps
     in <quote>no such operator</quote> failures which can be resolved by adding
     parentheses.  However there are corner cases in which a query might
     change behavior without any parsing error being reported.
    </para>
   </note>
  </sect2>
 </sect1>

 <sect1 id="sql-expressions">
  <title>Value Expressions</title>

  <indexterm zone="sql-expressions">
   <primary>expression</primary>
   <secondary>syntax</secondary>
  </indexterm>

  <indexterm zone="sql-expressions">
   <primary>value expression</primary>
  </indexterm>

  <indexterm>
   <primary>scalar</primary>
   <see>expression</see>
  </indexterm>

  <para>
   Value expressions are used in a variety of contexts, such
   as in the target list of the <command>SELECT</command> command, as
   new column values in <command>INSERT</command> or
   <command>UPDATE</command>, or in search conditions in a number of
   commands.  The result of a value expression is sometimes called a
   <firstterm>scalar</firstterm>, to distinguish it from the result of
   a table expression (which is a table).  Value expressions are
   therefore also called <firstterm>scalar expressions</firstterm> (or
   even simply <firstterm>expressions</firstterm>).  The expression
   syntax allows the calculation of values from primitive parts using
   arithmetic, logical, set, and other operations.
  </para>

  <para>
   A value expression is one of the following:

   <itemizedlist>
    <listitem>
     <para>
      A constant or literal value
     </para>
    </listitem>

    <listitem>
     <para>
      A column reference
     </para>
    </listitem>

    <listitem>
     <para>
      A positional parameter reference, in the body of a function definition
      or prepared statement
     </para>
    </listitem>

    <listitem>
     <para>
      A subscripted expression
     </para>
    </listitem>

    <listitem>
     <para>
      A field selection expression
     </para>
    </listitem>

    <listitem>
     <para>
      An operator invocation
     </para>
    </listitem>

    <listitem>
     <para>
      A function call
     </para>
    </listitem>

    <listitem>
     <para>
      An aggregate expression
     </para>
    </listitem>

    <listitem>
     <para>
      A window function call
     </para>
    </listitem>

    <listitem>
     <para>
      A type cast
     </para>
    </listitem>

    <listitem>