Production rule systems are conceptually simple, but there are many subtle points involved in actually using them. Some of these points and the theoretical foundations of the Postgres rule system can be found in [Stonebraker et al, ACM, 1990].
本番で稼働するルールシステムは概念としては単純ですが、 実際に使ってみると、判りにくいところが少なからずあります。 これらいくつかの判りにくいところと、 Postgresのルールシステムにおける 基本的な理論についは [Stonebraker et al, ACM, 1990] に書かれています。
Some other database systems define active database rules. These are usually stored procedures and triggers and are implemented in Postgres as functions and triggers.
他のいくつかのデータベースシステムは能動的データベースルールを 定義しています。通常それらはストアドプロシージャとトリガで、 Postgres では関数とトリガとして 実装されています。
The query rewrite rule system (the "rule system" from now on) is totally different from stored procedures and triggers. It modifies queries to take rules into consideration, and then passes the modified query to the query optimizer for execution. It is very powerful, and can be used for many things such as query language procedures, views, and versions. The power of this rule system is discussed in [Ong and Goh, 1990] as well as [Stonebraker et al, ACM, 1990].
問合せ書き換えシステム(以降、"ルールシステム"と呼びます)は 内蔵プロシージャとトリガとは全く異なります。 ルールシステムはルールを考察して問合せを修正し、 修正した問合せを、実行のためオプティマイザに渡します。 これは非常に強力なため、問合せ言語プロシージャ、ビューあるいは バージョンなど多くのパターンで使用することが出来ます。 このルールシステムの能力は [Ong and Goh, 1990] だけでなく [Stonebraker et al, ACM, 1990] でも解説されています。
To understand how the rule system works it is necessary to know when it is invoked and what it's input and results are.
どのようにルールシステムが機能するかを理解するためには まずルールがどのように起動されその入力と結果とは何かを 理解しなければなりません。
The rule system is located between the query parser and the optimizer. It takes the output of the parser, one querytree, and the rewrite rules from the pg_rewrite catalog, which are querytrees too with some extra information, and creates zero or many querytrees as result. So it's input and output are always things the parser itself could have produced and thus, anything it sees is basically representable as an SQL statement.
ルールシステムは問合せのパーサとオプティマイザの中間に位置します。 ルールシステムは、入力としてパーサの出力と単一の問合せツリーおよび pg_rewrite カタログから、何らかの特別な情報を 持つ問合せツリーでもある書き換えルールを取得し、結果としてゼロから 複数個の問合せツリーを生成します。 ルールシステムの入力と出力は常にパーサ自体でも生成すること が出来るもので、参照する対象は基本的に SQL 文による式です。
Now what is a querytree? It is an internal representation of an SQL statement where the single parts that built it are stored separately. These querytrees are visible when starting the Postgres backend with debuglevel 4 and typing queries into the interactive backend interface. The rule actions in the pg_rewrite system catalog are also stored as querytrees. They are not formatted like the debug output, but they contain exactly the same information.
では問合せツリーとは何でしょうか。それは生成されたひとつ ひとつのパーツが別々にどこに記憶されるかの SQL 文の内部表現です。Postgres バックエンド をデバッグレベル 4 で起動し、対話型バックエンドインターフェイスを使って 問合せを入力することによって問合せツリーを見ることが出来ます。 pg_rewrite システムカタログ内のルール アクションは同時に、問合せツリーとして記憶されます。それらは デバッグの出力のようにフォーマットされてはいませんが全く同じ情報 を持っています。
Reading a querytree requires some experience and it was a hard time when I started to work on the rule system. I can remember that I was standing at the coffee machine and I saw the cup in a targetlist, water and coffee powder in a rangetable and all the buttons in a qualification expression. Since SQL representations of querytrees are sufficient to understand the rule system, this document will not teach how to read them. It might help to learn it and the naming conventions are required in the later following descriptions.
問合せツリーを読むためには多少の経験が必要なので筆者がルール システムについての作業を始めたときは大変でした。 コーヒメーカの前に立っていてコップを目的リストに、お湯と コーヒー粉を範囲テーブルに、そしてすべての操作ボタンを 条件式だと思い浮かべたことを思い出します。 問合せツリーの SQL の式はルールシステムを 理解するのに充分ですからこのドキュメントではどのように問合せ ツリーを読むのかには触れません。それらの理解と慣例を例示する ようになるには将来出て来る書類にまかせます。
When reading the SQL representations of the querytrees in this document it is necessary to be able to identify the parts the statement is broken into when it is in the querytree structure. The parts of a querytree are
このドキュメントで問合せツリーのSQL 式を読む 場合には、問合せツリーの構造内にあって問合せ文が分解された パーツがどれであるか見極めることができる必要があります。 問合せツリーのパーツとは以下に記述するものです。
This is a simple value telling which command (SELECT, INSERT, UPDATE, DELETE) produced the parsetree.
どのコマンド (SELECT、 INSERT、 UPDATE、 DELETE) が パースツリーを生成したかを示す単純な値です。
The rangtable is a list of relations that are used in the query. In a SELECT statement that are the relations given after the FROM keyword.
範囲テーブルは問合せの中で使われるリレーションのリストです。 SELECT 文では FROM キーワードの後に与えられるものが リレーションです。
Every rangetable entry identifies a table or view and tells by which name it is called in the other parts of the query. In the querytree the rangetable entries are referenced by index rather than by name, so here it doesn't matter if there are duplicate names as it would in an SQL statement. This can happen after the rangetables of rules have been merged in. The examples in this document will not have this situation.
それぞれの範囲テーブルの項目はテーブルまたはビューを特定 し、他の問合せによるパーツではどのような名前で呼ばれている のかを通知します。問合せツリーにおいて範囲テーブルは名前で はなくインデックスで参照されますので SQL 文の中と同様に重複した名前が存在しても構いません。 この状況はルールの範囲テーブルがマージされた後に起こること があります。このドキュメントであげている例ではそうはなりま せん。
This is an index into the rangetable that identifies the relation where the results of the query go.
問合せの結果がどこに行くのかのリレーションを特定する 範囲テーブルへのインデックスです。
SELECT queries normally don't have a result relation. The special case of a SELECT INTO is mostly identical to a CREATE TABLE, INSERT ... SELECT sequence and is not discussed separately here.
通常 SELECT は結果のリレーションを持ちません。 SELECT INTO の特殊な場合は CREATE TABLE、INSERT ... SELECT の流れとほぼ同等なので、一緒に説明します。
On INSERT, UPDATE and DELETE queries the resultrelation is the table (or view!) where the changes take effect.
INSERT、UPDATE および DELETE において結果のリレーション はどこで変更が有効となるかのテーブル(または ビュー!)です。
The targetlist is a list of expressions that define the result of the query. In the case of a SELECT, the expressions are what builds the final output of the query. They are the expressions between the SELECT and the FROM keywords (* is just an abbreviation for all the attribute names of a relation).
目的リストは問合せの結果を定義する式のリストで、SELECT の場合 式は、問合せの最終出力を組み立てたものです。 それらは SELECT と FROM キーワードの間の式です。 (* はリレーションの全ての属性名にたいする単なる省略形です。)
DELETE queries don't need a targetlist because they don't produce any result. In fact the optimizer will add a special entry to the empty targetlist. But this is after the rule system and will be discussed later. For the rule system the targetlist is empty.
DELETE は何の結果ももたらしませんので目的リストを必要と しません。実際にはオプティマイザは空の目的リストに特殊な 項目を付け加えます。しかしこのことはルールシステムの後 に起こることなので後述することにします。ルールシステムに 関して言えば目的リストは空です。
In INSERT queries the targetlist describes the new rows that should go into the resultrelation. Missing columns of the resultrelation will be added by the optimizer with a constant NULL expression. It is the expressions in the VALUES clause or the ones from the SELECT clause on INSERT ... SELECT.
INSERT では目的リストは結果のリレーションへ行く新規の行を 記述します。結果のリレーションで抜けているカラムは、 オプティマイザが定数 NULL 式を付け加えます。 これは VALUES 句における、または INSERT ... SELECT における SELECT 句からの式です。
On UPDATE queries, it describes the new rows that should replace the old ones. Here now the optimizer will add missing columns by inserting expressions that put the values from the old rows into the new one. And it will add the special entry like for DELETE too. It is the expressions from the SET attribute = expression part of the query.
UPDATE では以前の行を置き換える新規の行を記述します。ここで オプティマイザは抜けているカラムに前の行からの値を、新規の行に 入れる式を挿入します。それと同時に DELETE で行ったと同じ特殊 項目を付け加えます。それは問合わせの SET 属性 = 式 の部分から の式です。
Every entry in the targetlist contains an expression that can be a constant value, a variable pointing to an attribute of one of the relations in the rangetable, a parameter or an expression tree made of function calls, constants, variables, operators etc.
目的リストのそれぞれの項目は、定数値のこともある式、 範囲テーブル内のリレーションのうちの一つの属性を指し示す変数、 関数呼び出しにより作られたパラメータあるいは式のツリー、定数、 変数、演算子などを持っています。
The queries qualification is an expression much like one of those contained in the targetlist entries. The result value of this expression is a boolean that tells if the operation (INSERT, UPDATE, DELETE or SELECT) for the final result row should be executed or not. It is the WHERE clause of an SQL statement.
問合せの条件は目的リストの項目に含まれているような式 です。この式の結果は (INSERT、 UPDATE、 DELETE または SELECT) 操作によって最終行が処理されたかどうかを示すブール値です。 それは SQL 文の中の WHERE 句です。
The other parts of the querytree like the ORDER BY clause arent of interest here. The rule system substitutes entries there while applying rules, but that doesn't have much to do with the fundamentals of the rule system. GROUP BY is a special thing when it appears in a view definition and still needs to be documented.
ORDER BY 句のような問合せツリーのその他のパーツには ここでは取り上げません。ルールシステムはルールを適用 しているときにそこの場所で項目を入れ換えますが、これは ルールシステムの基本とはあまり関係しません。GROUP BY はビューの定義に出てきたときは特別なもので、別途に ドキュメント化されるべきです。