schema-qualified) of a function that is an
      index method support function for the operator class.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argument_type</replaceable></term>
    <listitem>
     <para>
      The parameter data type(s) of the function.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">storage_type</replaceable></term>
    <listitem>
     <para>
      The data type actually stored in the index.  Normally this is
      the same as the column data type, but some index methods
      (currently GiST, GIN, SP-GiST and BRIN) allow it to be different.  The
      <literal>STORAGE</literal> clause must be omitted unless the index
      method allows a different type to be used.
      If the column <replaceable class="parameter">data_type</replaceable> is specified
      as <type>anyarray</type>, the <replaceable class="parameter">storage_type</replaceable>
      can be declared as <type>anyelement</type> to indicate that the index
      entries are members of the element type belonging to the actual array
      type that each particular index is created for.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   The <literal>OPERATOR</literal>, <literal>FUNCTION</literal>, and <literal>STORAGE</literal>
   clauses can appear in any order.
  </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   Because the index machinery does not check access permissions on functions
   before using them, including a function or operator in an operator class
   is tantamount to granting public execute permission on it.  This is usually
   not an issue for the sorts of functions that are useful in an operator
   class.
  </para>

  <para>
   The operators should not be defined by SQL functions.  An SQL function
   is likely to be inlined into the calling query, which will prevent
   the optimizer from recognizing that the query matches an index.
  </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   The following example command defines a GiST index operator class
   for the data type <literal>_int4</literal> (array of <type>int4</type>).  See the
   <xref linkend="intarray"/> module for the complete example.
  </para>

<programlisting>
CREATE OPERATOR CLASS gist__int_ops
    DEFAULT FOR TYPE _int4 USING gist AS
        OPERATOR        3       &amp;&amp;,
        OPERATOR        6       = (anyarray, anyarray),
        OPERATOR        7       @&gt;,
        OPERATOR        8       &lt;@,
        OPERATOR        20      @@ (_int4, query_int),
        FUNCTION        1       g_int_consistent (internal, _int4, smallint, oid, internal),
        FUNCTION        2       g_int_union (internal, internal),
        FUNCTION        3       g_int_compress (internal),
        FUNCTION        4       g_int_decompress (internal),
        FUNCTION        5       g_int_penalty (internal, internal, internal),
        FUNCTION        6       g_int_picksplit (internal, internal),
        FUNCTION        7       g_int_same (_int4, _int4, internal);
</programlisting>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   <command>CREATE OPERATOR CLASS</command> is a
   <productname>PostgreSQL</productname> extension.  There is no
   <command>CREATE OPERATOR CLASS</command> statement in the SQL
   standard.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-alteropclass"/></member>
   <member><xref linkend="sql-dropopclass"/></member>
   <member><xref linkend="sql-createopfamily"/></member>
   <member><xref linkend="sql-alteropfamily"/></member>
  </simplelist>
 </refsect1>
</refentry>