The pg_am table contains one row for every
index access method. Support for access to regular tables is
built into PostgreSQL, but all index access
methods are described in pg_am. It is possible
to add a new index access method by defining the required interface
routines and then creating a row in pg_am ---
but that is far beyond the scope of this chapter.
The routines for an index access method do not directly know anything about the data types the access method will operate on. Instead, an operator class identifies the set of operations that the access method needs to be able to use to work with a particular data type. Operator classes are so called because one thing they specify is the set of WHERE-clause operators that can be used with an index (ie, can be converted into an index scan qualification). An operator class may also specify some support procedures that are needed by the internal operations of the index access method, but do not directly correspond to any WHERE-clause operator that can be used with the index.
It is possible to define multiple operator classes for the same input data type and index access method. By doing this, multiple sets of indexing semantics can be defined for a single data type. For example, a B-tree index requires a sort ordering to be defined for each data type it works on. It might be useful for a complex-number data type to have one B-tree operator class that sorts the data by complex absolute value, another that sorts by real part, and so on. Typically one of the operator classes will be deemed most commonly useful and will be marked as the default operator class for that data type and index access method.
The same operator class name can be used for several different access methods (for example, both B-tree and hash access methods have operator classes named oid_ops), but each such class is an independent entity and must be defined separately.