For each combination of data types that a btree operator family provides comparison operators for, it must provide a comparison support function, registered in <structname>pg_amproc</structname> with support function number 1 and <structfield>amproclefttype</structfield>/<structfield>amprocrighttype</structfield> equal to the left and right data types for the comparison (i.e., the same data types that the matching operators are registered with in <structname>pg_amop</structname>). The comparison function must take two non-null values <replaceable>A</replaceable> and <replaceable>B</replaceable> and return an <type>int32</type> value that is <literal>&lt;</literal> <literal>0</literal>, <literal>0</literal>, or <literal>&gt;</literal> <literal>0</literal> when <replaceable>A</replaceable> <literal>&lt;</literal> <replaceable>B</replaceable>, <replaceable>A</replaceable> <literal>=</literal> <replaceable>B</replaceable>, or <replaceable>A</replaceable> <literal>&gt;</literal> <replaceable>B</replaceable>, respectively. A null result is disallowed: all values of the data type must be comparable. See <filename>src/backend/access/nbtree/nbtcompare.c</filename> for examples. btreeの演算子族が比較演算子を提供する各データ型の組み合わせに対して、比較サポート関数を提供しなければなりません。それらはサポート関数1番でpg_amprocに、また、比較での左右のデータ型と等しいamproclefttype/amprocrighttypeに、登録されます（すなわち、pg_amopに登録されている演算子が対応するものと同じデータ型です）。 比較関数は2つの非NULL値AとBを取り、 A < B、A = B、または、A > Bであるときにそれぞれ、< 0、0、または、> 0であるint32の値を返さなければなりません。 NULLの結果は許されず、データ型の全ての値は比較可能でなければなりません。 例としてsrc/backend/access/nbtree/nbtcompare.cを参照してください。

If the compared values are of a collatable data type, the appropriate collation OID will be passed to the comparison support function, using the standard <function>PG_GET_COLLATION()</function> mechanism. 比較される値が照合順序が適用可能なデータ型のものである場合、比較サポート関数に適切な照合順序のOIDが渡され、標準のPG_GET_COLLATION()機構が使用されます。

Optionally, a btree operator family may provide <firstterm>sort support</firstterm> function(s), registered under support function number 2. These functions allow implementing comparisons for sorting purposes in a more efficient way than naively calling the comparison support function. The APIs involved in this are defined in <filename>src/include/utils/sortsupport.h</filename>. 任意で、btree演算子族はソートサポート関数を提供してもよいです。これはサポート関数2番で登録されます。 この関数は、素朴に比較サポート関数を呼び出すよりも、ソート目的により効果的な方法での比較の実装を可能にします。 これに関するAPIはsrc/include/utils/sortsupport.hで定義されています。

Optionally, a btree operator family may provide <firstterm>in_range</firstterm> support function(s), registered under support function number 3. These are not used during btree index operations; rather, they extend the semantics of the operator family so that it can support window clauses containing the <literal>RANGE</literal> <replaceable>offset</replaceable> <literal>PRECEDING</literal> and <literal>RANGE</literal> <replaceable>offset</replaceable> <literal>FOLLOWING</literal> frame bound types (see <xref linkend="syntax-window-functions"/>). Fundamentally, the extra information provided is how to add or subtract an <replaceable>offset</replaceable> value in a way that is compatible with the family's data ordering. 任意で、btree演算子族はin_rangeサポート関数を提供してもよいです。これはサポート関数3番に登録されます。 これはbtreeインデックス操作中には使われません。そうではなく、演算子族のセマンティクスをRANGE offset PRECEDINGとRANGE offset FOLLOWINGフレーム境界タイプ（4.2.8を参照）を含むWINDOW句に対応できるように拡張します。 基本的には、提供される拡張情報はどのように演算子族のデータ並び順と互換性のある方法でoffset値を足すか引くかです。

An <function>in_range</function> function must have the signature in_range関数は以下のシグネチャを持たなければなりません。

in_range(val type1, base type1, offset type2, sub bool, less bool)
returns bool

<replaceable>val</replaceable> and <replaceable>base</replaceable> must be of the same type, which is one of the types supported by the operator family (i.e., a type for which it provides an ordering). However, <replaceable>offset</replaceable> could be of a different type, which might be one otherwise unsupported by the family. An example is that the built-in <literal>time_ops</literal> family provides an <function>in_range</function> function that has <replaceable>offset</replaceable> of type <type>interval</type>. A family can provide <function>in_range</function> functions for any of its supported types and one or more <replaceable>offset</replaceable> types. Each <function>in_range</function> function should be entered in <structname>pg_amproc</structname> with <structfield>amproclefttype</structfield> equal to <type>type1</type> and <structfield>amprocrighttype</structfield> equal to <type>type2</type>. valとbaseは同じ型でなければならず、これは演算子族でサポートされる型の一つ（すなわち、並び順を提供する対象の型）です。 しかしながら、offsetは異なる型のものでも可能です。それは演算子族でサポートされないものでもよいです。 例としては、組み込みのtime_ops族がinterval型のoffsetを持つin_range関数を提供しています。 演算子族は、任意のサポートされる型と一つまたは複数のoffset型に対するin_range関数を提供できます。 各in_range関数は、pg_amprocにtype1と等しいamproclefttypeとtype2に等しいamproclefttypeで登録されるべきです。

The essential semantics of an <function>in_range</function> function depend on the two Boolean flag parameters. It should add or subtract <replaceable>base</replaceable> and <replaceable>offset</replaceable>, then compare <replaceable>val</replaceable> to the result, as follows: in_range関数の本質的なセマンティクスは2つのBooleanフラグパラメータに依存します。 これは以下のように、baseにoffsetを加算または減算して、それからvalを結果と比較すべきです。

Before doing so, the function should check the sign of <replaceable>offset</replaceable>: if it is less than zero, raise error <literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal> (22013) with error text like <quote>invalid preceding or following size in window function</quote>. (This is required by the SQL standard, although nonstandard operator families might perhaps choose to ignore this restriction, since there seems to be little semantic necessity for it.) This requirement is delegated to the <function>in_range</function> function so that the core code needn't understand what <quote>less than zero</quote> means for a particular data type. このように実行する前に、本関数は、offsetの符号を検査すべきです。 すなわち、負であったなら、エラーERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE(22013)、エラー文面としては「invalid preceding or following size in window function(ウィンドウ関数で先行または後続のサイズが不正です)」などを出すことです。 （意味上の必要性が乏しいと見られることから非標準の演算子族はこの制限を無視することを選ぶかもしれませんが、これは標準SQLで必要とされています。） 中核コードが特定のデータ型における「ゼロより小さい」ことの意味を理解しなくても良いように、この要件はin_range関数に委託されます。

An additional expectation is that <function>in_range</function> functions should, if practical, avoid throwing an error if <replaceable>base</replaceable> <literal>+</literal> <replaceable>offset</replaceable> or <replaceable>base</replaceable> <literal>-</literal> <replaceable>offset</replaceable> would overflow. The correct comparison result can be determined even if that value would be out of the data type's range. Note that if the data type includes concepts such as <quote>infinity</quote> or <quote>NaN</quote>, extra care may be needed to ensure that <function>in_range</function>'s results agree with the normal sort order of the operator family. さらに期待されることは、in_range関数は、実用的には、base + offsetやbase - offsetがオーバーフローする場合にエラーを投げるのを避けるべきです。 たとえ値がデータ型の範囲を超えたとしても正しい比較結果は決定できます。 データ型が「infinity」や「NaN」などの概念を含む場合には、in_rangeの結果が演算子族の通常のソート順序と一致するように特別な対応が必要となることに注意してください。

The results of the <function>in_range</function> function must be consistent with the sort ordering imposed by the operator family. To be precise, given any fixed values of <replaceable>offset</replaceable> and <replaceable>sub</replaceable>, then: in_range関数の結果は、演算子族で規定されるソート順序と整合していなければなりません。 正確には、与えらえれた任意のoffsetとsubの修正値は以下のようになります。

Analogous statements with inverted conditions hold when <replaceable>less</replaceable> = false. less = falseのときには、逆条件の類似した命題が適用できます。

If the type being ordered (<type>type1</type>) is collatable, the appropriate collation OID will be passed to the <function>in_range</function> function, using the standard PG_GET_COLLATION() mechanism. 整列しようとしている型(type1)が照合可能であるなら、標準のPG_GET_COLLATION()機構を使って、in_range関数に適切な照合順序のOIDが渡されます。

<function>in_range</function> functions need not handle NULL inputs, and typically will be marked strict. in_range関数は、通例STRICTと印付けされ、NULL入力を処理する必要がありません。

Optionally, a btree operator family may provide <function>equalimage</function> (<quote>equality implies image equality</quote>) support functions, registered under support function number 4. These functions allow the core code to determine when it is safe to apply the btree deduplication optimization. Currently, <function>equalimage</function> functions are only called when building or rebuilding an index. 省略可能ですが、btree演算子族はequalimage (「イメージ等価を意味する等価」)サポート関数を提供してもよいです。これはサポート関数4番で登録されます。 この関数は、中核コードがbtree重複排除の最適化を適用するのが安全かを決定できるようにします。 今のところ、equalimage関数はインデックスの構築または再構築時にのみ呼び出されます。

An <function>equalimage</function> function must have the signature equalimage関数は以下のシグネチャを持たなければなりません。

equalimage(opcintype oid) returns bool

The return value is static information about an operator class and collation. Returning <literal>true</literal> indicates that the <function>order</function> function for the operator class is guaranteed to only return <literal>0</literal> (<quote>arguments are equal</quote>) when its <replaceable>A</replaceable> and <replaceable>B</replaceable> arguments are also interchangeable without any loss of semantic information. Not registering an <function>equalimage</function> function or returning <literal>false</literal> indicates that this condition cannot be assumed to hold. 戻り値は演算子クラスと照合順序についての静的な情報です。 trueを返すことは、AおよびB引数が何らセマンティック情報を損失すること無しに交換可能でもあるとき、演算子クラスに対するorder関数が0（「引数が等しい」）だけを返すことが保証されていることを示します。 equalimage関数が登録されていなかったり、falseを返すことは、この条件は守られないであろうことを示します。

The <replaceable>opcintype</replaceable> argument is the <literal><structname>pg_type</structname>.oid</literal> of the data type that the operator class indexes. This is a convenience that allows reuse of the same underlying <function>equalimage</function> function across operator classes. If <replaceable>opcintype</replaceable> is a collatable data type, the appropriate collation OID will be passed to the <function>equalimage</function> function, using the standard <function>PG_GET_COLLATION()</function> mechanism. opcintype引数は演算子クラスタがインデックスを作るデータ型のpg_type.oidです。 これは同じ基となるequalimage関数を演算子クラスを横断して再利用できるようになる利便性があります。 opcintypeが照合可能なデータ型である場合には、適切な照合順序のOIDが、標準のPG_GET_COLLATION()機構を使って、equalimage関数に渡されます。

As far as the operator class is concerned, returning <literal>true</literal> indicates that deduplication is safe (or safe for the collation whose OID was passed to its <function>equalimage</function> function). However, the core code will only deem deduplication safe for an index when <emphasis>every</emphasis> indexed column uses an operator class that registers an <function>equalimage</function> function, and each function actually returns <literal>true</literal> when called. 演算子クラスに関する限り、trueを返すことは、重複排除が安全（あるいはequalimage関数に渡されたOIDの照合順序について安全）であることを示します。 しかしながら、コアコードは、全てのインデックス列がequalimage関数を登録する演算子クラスを使っていて、各関数が呼ばれたとき実際にtrueを返すときに、そのインデックスに対して重複排除を安全と見做すだけです。

Image equality is <emphasis>almost</emphasis> the same condition as 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). イメージ等価は単純にビット毎に等しいこととほとんど同じ条件です。 一点微妙な違いがあります。varlenaデータ型にインデックス作成するとき、入力時の一貫性のないTOAST圧縮の適用のために、同じdatumの二つのイメージのディスク上の表現はビット毎には等しくないかもしれません。 これまでは、演算子クラスのequalimage関数がtrueを返すときには、datum_image_eq() C関数が常に演算子クラスのorder関数と一致すると想定して安全でした（同じ照合順序のOIDがequalimageとorderの両関数に渡されるとして）。

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. コアコードは基本的に、複数データ型の族の中の演算子クラスの「等価性がイメージ等価性を含む」状態について、同族の他の演算子クラスの詳細に基づいた、いかなる推測もできません。 また、ある演算子族が型にまたがってequalimage関数を登録していることを認識できず、そのような試みはエラーになります。 これは「等価性がイメージ等価性を含む」状態は、演算子族の階層でおおむね定義されている、ソートと等価性のセマンティクスに依存しているだけでは無いためです。 一般に、ある特定データ型の実装によるセマンティクスは別個に考慮されなければなりません。

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. コアPostgreSQL配布物に含まれる演算子クラスが従う慣習は、標準品、すなわち、一般的なequalimage関数を登録することです。 大部分の演算子クラスタはbtequalimage()を登録しています。これは重複排除が無条件に安全であることを示しています。 textなどの照合可能なデータ型に対する演算子クラスはbtvarstrequalimage()を登録します。これは決定的な照合順序では重複排除が安全であることを示します。 サードパーティ拡張におけるベストプラクティスは制御を保つためにそれら自身のカスタム関数を登録することです。

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. 省略可能ですが、B-treeの演算子族はoptions（「演算子クラス固有オプション」）サポート関数を提供してもよいです。これはサポート関数5番に登録されます。 この関数はユーザに見える演算子クラスの振る舞いを制御するパラメータの集合を定義します。

An <function>options</function> support function must have the signature optionsサポート関数は以下のシグネチャを持たなければなりません。

options(relopts local_relopts *) returns void

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. 関数にはlocal_relopts構造体へのポインタが渡されます。ここには演算子クラス固有のオプションの集合が書かれている必要があります。 このオプションにはPG_HAS_OPCLASS_OPTIONS()およびPG_GET_OPCLASS_OPTIONS()マクロを使って他のサポート関数からアクセスが可能です。

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>. 今のところ、optionsサポート関数を持ったB-Treeの演算子クラスはありません。 B-treeはGiST、SP-GiST、GINおよびBRINで行われているような柔軟なキーの表現を許していません。 そのため、おそらくはoptionsが現在のB-treeインデックスアクセスメソッドで多数適用されることはありません。 それでも、統一性のためにサポート関数がB-treeに追加されました。おそらくPostgreSQLでのB-treeの更なる進化の過程で使用法を見つけ出すでしょう。