As shown in <xref linkend="xindex-btree-strat-table"/>, a btree operator class must provide five comparison operators, <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>=</literal>, <literal>&gt;=</literal> and <literal>&gt;</literal>. One might expect that <literal>&lt;&gt;</literal> should also be part of the operator class, but it is not, because it would almost never be useful to use a <literal>&lt;&gt;</literal> WHERE clause in an index search. (For some purposes, the planner treats <literal>&lt;&gt;</literal> as associated with a btree operator class; but it finds that operator via the <literal>=</literal> operator's negator link, rather than from <structname>pg_amop</structname>.) 表 38.3で示すように、btree演算子クラスは次の5つの比較演算子を提供しなければなりません。 <、<=、=、>=、そして>です。 <>も演算子クラスの一部であると期待する方もいるかもしれませんが、そうではありません。 インデックス検索のWHERE句で<>を使うのは、ほとんど常に役に立たないからです。 （ある種の目的のためにプランナは<>をbtree演算子クラスに関連しているものとして扱います。 しかし、プランナはpg_amopから検索するのではなく=の否定子リンクから検索します。）

When several data types share near-identical sorting semantics, their operator classes can be grouped into an operator family. Doing so is advantageous because it allows the planner to make deductions about cross-type comparisons. Each operator class within the family should contain the single-type operators (and associated support functions) for its input data type, while cross-type comparison operators and support functions are <quote>loose</quote> in the family. It is recommendable that a complete set of cross-type operators be included in the family, thus ensuring that the planner can represent any comparison conditions that it deduces from transitivity. 複数のデータ型がほとんど同じソートセマンティクスを共有している場合、それらの演算子クラスは演算子族にまとめることができます。 そうすることによりプランナが型をまたがる比較を推論できるので、これはメリットがあります。 ファミリー中の演算子クラスには、入力データ型のための単一型演算子（および関連するサポート関数）が含まれます。 一方型をまたがる比較演算子とサポート関数は演算子族中で「ゆるやか」です。 プランナが推移関係から推論するすべての比較条件を提示できるように、型をまたがる演算子の完全な集合を演算子族に入れておくことをお勧めします。

There are some basic assumptions that a btree operator family must satisfy: btree演算子族が満たさなければならない基本的な前提条件があります。

The other three operators are defined in terms of <literal>=</literal> and <literal>&lt;</literal> in the obvious way, and must act consistently with them. 他の3つの演算子は=と<に沿って自明に定義され、それらと一貫していなければなりません。

For an operator family supporting multiple data types, the above laws must hold when <replaceable>A</replaceable>, <replaceable>B</replaceable>, <replaceable>C</replaceable> are taken from any data types in the family. The transitive laws are the trickiest to ensure, as in cross-type situations they represent statements that the behaviors of two or three different operators are consistent. As an example, it would not work to put <type>float8</type> and <type>numeric</type> into the same operator family, at least not with the current semantics that <type>numeric</type> values are converted to <type>float8</type> for comparison to a <type>float8</type>. Because of the limited accuracy of <type>float8</type>, this means there are distinct <type>numeric</type> values that will compare equal to the same <type>float8</type> value, and thus the transitive law would fail. 複数のデータ型をサポートする演算子族について、演算子族中のデータ型であるどんなA、B、Cも上記の法則を満たさなければなりません。 型をまたがる際に2つあるいは3つの異なる演算子が一貫していることを表明することになるので、推移律を満たすことはもっとも困難です。 例をあげると、少なくともfloat8と比較するためにnumeric値をfloat8に変換する現在の意味論のもとでは、float8とnumericを同じ演算子族に加えるのはうまくいかないでしょう。 float8の精度に限りがあるからです。 これは同じfloat8値に対して等号比較する複数の異なるnumeric値が存在することを意味し、したがって推移律は満たされません。

Another requirement for a multiple-data-type family is that any implicit or binary-coercion casts that are defined between data types included in the operator family must not change the associated sort ordering. 複数データ型ファミリーに関する別な要件は、演算子族に含まれるデータ型間に定義される暗黙的あるいは二値型強制(binary-coercion)キャストは、関係するソート順を変更してはならないことです。

It should be fairly clear why a btree index requires these laws to hold within a single data type: without them there is no ordering to arrange the keys with. Also, index searches using a comparison key of a different data type require comparisons to behave sanely across two data types. The extensions to three or more data types within a family are not strictly required by the btree index mechanism itself, but the planner relies on them for optimization purposes. 単一のデータ型において、btreeインデックスがこれらの法則を守ることを要求するのはかなり明確です。 これらの法則なしにはキー並べる順序がなくなってしまうからです。 また、異なるデータ型の比較キーを使うインデックス検索では、2つのデータ型またがる比較が正常に動作することが必要です。 演算子族中で3つ以上のデータ型に対する拡張はbtreeインデックスの機構自体では要求されませんが、プランナは最適化の目的でそれらに依存します。