simple bitwise equality.  There is one subtle difference: When
     indexing a varlena data type, the on-disk representation of two
     image equal datums may not be bitwise equal due to inconsistent
     application of <acronym>TOAST</acronym> compression on input.
     Formally, when an operator class's
     <function>equalimage</function> function returns
     <literal>true</literal>, it is safe to assume that the
     <literal>datum_image_eq()</literal> C function will always agree
     with the operator class's <function>order</function> function
     (provided that the same collation OID is passed to both the
     <function>equalimage</function> and <function>order</function>
     functions).
    </para>
    <para>
     The core code is fundamentally unable to deduce anything about
     the <quote>equality implies image equality</quote> status of an
     operator class within a multiple-data-type family based on
     details from other operator classes in the same family.  Also, it
     is not sensible for an operator family to register a cross-type
     <function>equalimage</function> function, and attempting to do so
     will result in an error.  This is because <quote>equality implies
      image equality</quote> status does not just depend on
     sorting/equality semantics, which are more or less defined at the
     operator family level.  In general, the semantics that one
     particular data type implements must be considered separately.
    </para>
    <para>
     The convention followed by the operator classes included with the
     core <productname>PostgreSQL</productname> distribution is to
     register a stock, generic <function>equalimage</function>
     function.  Most operator classes register
     <function>btequalimage()</function>, which indicates that
     deduplication is safe unconditionally.  Operator classes for
     collatable data types such as <type>text</type> register
     <function>btvarstrequalimage()</function>, which indicates that
     deduplication is safe with deterministic collations.  Best
     practice for third-party extensions is to register their own
     custom function to retain control.
    </para>
   </listitem>
  </varlistentry>
  <varlistentry>
   <term><function>options</function></term>
   <listitem>
    <para>
     Optionally, a B-tree operator family may provide
     <function>options</function> (<quote>operator class specific
     options</quote>) support functions, registered under support
     function number 5.  These functions define a set of user-visible
     parameters that control operator class behavior.
    </para>
    <para>
     An <function>options</function> support function must have the
     signature
<synopsis>
options(<replaceable>relopts</replaceable> <type>local_relopts *</type>) returns void
</synopsis>
     The function is passed a pointer to a <structname>local_relopts</structname>
     struct, which needs to be filled with a set of operator class
     specific options.  The options can be accessed from other support
     functions using the <literal>PG_HAS_OPCLASS_OPTIONS()</literal> and
     <literal>PG_GET_OPCLASS_OPTIONS()</literal> macros.
    </para>
    <para>
     Currently, no B-Tree operator class has an <function>options</function>
     support function.  B-tree doesn't allow flexible representation of keys
     like GiST, SP-GiST, GIN and BRIN do.  So, <function>options</function>
     probably doesn't have much application in the current B-tree index
     access method.  Nevertheless, this support function was added to B-tree
     for uniformity, and will probably find uses during further
     evolution of B-tree in <productname>PostgreSQL</productname>.
    </para>
   </listitem>
  </varlistentry>
  <varlistentry>
   <term><function>skipsupport</function></term>
   <listitem>
    <para>
     Optionally, a btree operator family may provide a <firstterm>skip
      support</firstterm> function, registered under support function number