discussed next.
    </para>
   </sect3>

   <sect3 id="sql-syntax-constants-generic">
    <title>Constants of Other Types</title>

    <indexterm>
     <primary>data type</primary>
     <secondary>constant</secondary>
    </indexterm>

    <para>
     A constant of an <emphasis>arbitrary</emphasis> type can be
     entered using any one of the following notations:
<synopsis>
<replaceable>type</replaceable> '<replaceable>string</replaceable>'
'<replaceable>string</replaceable>'::<replaceable>type</replaceable>
CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</synopsis>
     The string constant's text is passed to the input conversion
     routine for the type called <replaceable>type</replaceable>. The
     result is a constant of the indicated type.  The explicit type
     cast can be omitted if there is no ambiguity as to the type the
     constant must be (for example, when it is assigned directly to a
     table column), in which case it is automatically coerced.
    </para>

    <para>
     The string constant can be written using either regular SQL
     notation or dollar-quoting.
    </para>

    <para>
     It is also possible to specify a type coercion using a function-like
     syntax:
<synopsis>
<replaceable>typename</replaceable> ( '<replaceable>string</replaceable>' )
</synopsis>
     but not all type names can be used in this way; see <xref
     linkend="sql-syntax-type-casts"/> for details.
    </para>

    <para>
     The <literal>::</literal>, <literal>CAST()</literal>, and
     function-call syntaxes can also be used to specify run-time type
     conversions of arbitrary expressions, as discussed in <xref
     linkend="sql-syntax-type-casts"/>.  To avoid syntactic ambiguity, the
     <literal><replaceable>type</replaceable> '<replaceable>string</replaceable>'</literal>
     syntax can only be used to specify the type of a simple literal constant.
     Another restriction on the
     <literal><replaceable>type</replaceable> '<replaceable>string</replaceable>'</literal>
     syntax is that it does not work for array types; use <literal>::</literal>
     or <literal>CAST()</literal> to specify the type of an array constant.
    </para>

    <para>
     The <literal>CAST()</literal> syntax conforms to SQL.  The
     <literal><replaceable>type</replaceable> '<replaceable>string</replaceable>'</literal>
     syntax is a generalization of the standard: SQL specifies this syntax only
     for a few data types, but <productname>PostgreSQL</productname> allows it
     for all types.  The syntax with
     <literal>::</literal> is historical <productname>PostgreSQL</productname>
     usage, as is the function-call syntax.
    </para>
   </sect3>
  </sect2>

  <sect2 id="sql-syntax-operators">
   <title>Operators</title>

   <indexterm zone="sql-syntax-operators">
    <primary>operator</primary>
    <secondary>syntax</secondary>
   </indexterm>

   <para>
    An operator name is a sequence of up to <symbol>NAMEDATALEN</symbol>-1
    (63 by default) characters from the following list:
<literallayout>
+ - * / &lt; &gt; = ~ ! @ # % ^ &amp; | ` ?
</literallayout>

    There are a few restrictions on operator names, however:
    <itemizedlist>
     <listitem>
      <para>
       <literal>--</literal> and <literal>/*</literal> cannot appear
       anywhere in an operator name, since they will be taken as the
       start of a comment.
      </para>
     </listitem>

     <listitem>
      <para>
       A multiple-character operator name cannot end in <literal>+</literal> or <literal>-</literal>,
       unless the name also contains at least one of these characters:
<literallayout>
~ ! @ # % ^ &amp; | ` ?
</literallayout>
       For example, <literal>@-</literal> is an allowed operator name,
       but <literal>*-</literal> is not.  This restriction allows
       <productname>PostgreSQL</productname> to parse SQL-compliant
       queries without requiring spaces between tokens.
      </para>
     </listitem>