<parameter>prop</parameter> is <literal>AMPROP_UNKNOWN</literal>.
   Access methods can define custom property names by
   checking <parameter>propname</parameter> for a match (use <function>pg_strcasecmp</function>
   to match, for consistency with the core code); for names known to the core
   code, it's better to inspect <parameter>prop</parameter>.
   If the <structfield>amproperty</structfield> method returns <literal>true</literal> then
   it has determined the property test result: it must set <literal>*res</literal>
   to the Boolean value to return, or set <literal>*isnull</literal>
   to <literal>true</literal> to return a NULL.  (Both of the referenced variables
   are initialized to <literal>false</literal> before the call.)
   If the <structfield>amproperty</structfield> method returns <literal>false</literal> then
   the core code will proceed with its normal logic for determining the
   property test result.
  </para>

  <para>
   Access methods that support ordering operators should
   implement <literal>AMPROP_DISTANCE_ORDERABLE</literal> property testing, as the
   core code does not know how to do that and will return NULL.  It may
   also be advantageous to implement <literal>AMPROP_RETURNABLE</literal> testing,
   if that can be done more cheaply than by opening the index and calling
   <function>amcanreturn</function>, which is the core code's default behavior.
   The default behavior should be satisfactory for all other standard
   properties.
  </para>

  <para>
<programlisting>
char *
ambuildphasename (int64 phasenum);
</programlisting>
   Return the textual name of the given build phase number.
   The phase numbers are those reported during an index build via the
   <function>pgstat_progress_update_param</function> interface.
   The phase names are then exposed in the
   <structname>pg_stat_progress_create_index</structname> view.
  </para>

  <para>
<programlisting>
bool
amvalidate (Oid opclassoid);
</programlisting>
   Validate the catalog entries for the specified operator class, so far as
   the access method can reasonably do that.  For example, this might include
   testing that all required support functions are provided.
   The <function>amvalidate</function> function must return false if the opclass is
   invalid.  Problems should be reported with <function>ereport</function>
   messages, typically at <literal>INFO</literal> level.
  </para>

  <para>
<programlisting>
void
amadjustmembers (Oid opfamilyoid,
                 Oid opclassoid,
                 List *operators,
                 List *functions);
</programlisting>
   Validate proposed new operator and function members of an operator family,
   so far as the access method can reasonably do that, and set their
   dependency types if the default is not satisfactory.  This is called
   during <command>CREATE OPERATOR CLASS</command> and during
   <command>ALTER OPERATOR FAMILY ADD</command>; in the latter
   case <parameter>opclassoid</parameter> is <literal>InvalidOid</literal>.
   The <type>List</type> arguments are lists
   of <structname>OpFamilyMember</structname> structs, as defined
   in <filename>amapi.h</filename>.

   Tests done by this function will typically be a subset of those
   performed by <function>amvalidate</function>,
   since <function>amadjustmembers</function> cannot assume that it is
   seeing a complete set of members.  For example, it would be reasonable
   to check the signature of a support function, but not to check whether
   all required support functions are provided.  Any problems can be
   reported by throwing an error.

   The dependency-related fields of
   the <structname>OpFamilyMember</structname> structs are initialized by
   the core code to create hard dependencies on the opclass if this
   is <command>CREATE OPERATOR CLASS</command>, or soft dependencies on the
   opfamily if this is <command>ALTER OPERATOR FAMILY ADD</command>.
   <function>amadjustmembers</function> can adjust these fields if