As shown in <xref linkend="xindex-btree-support-table"/>, btree defines one required and four optional support functions. The five user-defined methods are: 表 38.9で示すように、btreeでは一つの必須サポート関数と、4つの省略可能なサポート関数を定義します。 5つのユーザ定義メソッドは以下の通りです。
order
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><</literal> <literal>0</literal>,
<literal>0</literal>, or <literal>></literal>
<literal>0</literal> when <replaceable>A</replaceable>
<literal><</literal> <replaceable>B</replaceable>,
<replaceable>A</replaceable> <literal>=</literal>
<replaceable>B</replaceable>, or <replaceable>A</replaceable>
<literal>></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()
機構が使用されます。
sortsupport
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
で定義されています。
in_range
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
を結果と比較すべきです。
if <literal>!</literal><replaceable>sub</replaceable> and
<literal>!</literal><replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>>=</literal>
(<replaceable>base</replaceable> <literal>+</literal>
<replaceable>offset</replaceable>)
!
sub
かつ
!
less
であるなら、
val
>=
(base
+
offset
)を返します
if <literal>!</literal><replaceable>sub</replaceable> and
<replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal><=</literal>
(<replaceable>base</replaceable> <literal>+</literal>
<replaceable>offset</replaceable>)
!
sub
かつ
less
であるなら、
val
<=
(base
+
offset
)を返します
if <replaceable>sub</replaceable> and
<literal>!</literal><replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal>>=</literal>
(<replaceable>base</replaceable> <literal>-</literal>
<replaceable>offset</replaceable>)
sub
かつ
!
less
であるなら、
val
>=
(base
-
offset
)を返します
if <replaceable>sub</replaceable> and
<replaceable>less</replaceable>, return
<replaceable>val</replaceable> <literal><=</literal>
(<replaceable>base</replaceable> <literal>-</literal>
<replaceable>offset</replaceable>)
sub
かつ
less
であるなら、
val
<=
(base
-
offset
)を返します
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
の修正値は以下のようになります。
If <function>in_range</function> with
<replaceable>less</replaceable> = true is true for some
<replaceable>val1</replaceable> and
<replaceable>base</replaceable>, it must be true for every
<replaceable>val2</replaceable> <literal><=</literal>
<replaceable>val1</replaceable> with the same
<replaceable>base</replaceable>.
less
= trueのin_range
がいくつかのval1
とbase
に対して真であるなら、同じbase
の全てのval2
<=
val1
に対して真でなければなりません。
If <function>in_range</function> with
<replaceable>less</replaceable> = true is false for some
<replaceable>val1</replaceable> and
<replaceable>base</replaceable>, it must be false for every
<replaceable>val2</replaceable> <literal>>=</literal>
<replaceable>val1</replaceable> with the same
<replaceable>base</replaceable>.
less
= trueのin_range
が、いくつかのval1
とbase
に対して偽であるなら、同じbase
の全てのval2
>=
val1
に対して偽でなければなりません。
If <function>in_range</function> with
<replaceable>less</replaceable> = true is true for some
<replaceable>val</replaceable> and
<replaceable>base1</replaceable>, it must be true for every
<replaceable>base2</replaceable> <literal>>=</literal>
<replaceable>base1</replaceable> with the same
<replaceable>val</replaceable>.
less
= trueのin_range
がいくつかのval
とbase1
に対して真であるなら、同じval
の全てのbase2
>=
base1
に対して真でなければなりません。
If <function>in_range</function> with
<replaceable>less</replaceable> = true is false for some
<replaceable>val</replaceable> and
<replaceable>base1</replaceable>, it must be false for every
<replaceable>base2</replaceable> <literal><=</literal>
<replaceable>base1</replaceable> with the same
<replaceable>val</replaceable>.
less
= trueのin_range
が一部のval
とbase1
に対して偽であるなら、同じval
の全てのbase2
<=
base1
に対して偽でなければなりません。
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入力を処理する必要がありません。
equalimage
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
.oidequalimage
関数を演算子クラスを横断して再利用できるようになる利便性があります。
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()
を登録します。これは決定的な照合順序では重複排除が安全であることを示します。
サードパーティ拡張におけるベストプラクティスは制御を保つためにそれら自身のカスタム関数を登録することです。
options
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の更なる進化の過程で使用法を見つけ出すでしょう。