}ここでeventは以下のうちの1つです。RULEにより、指定したテーブルまたはビューに適用するルールを新しく定義できます。RULEを使用すると、新しいルールの作成、または、同じテーブルの同じ名前の既存ルールの置き換えのいずれかを実行します。本来の操作の代替として実行するアクションを定義できます。簡単に言えば、指定されたテーブルに対して指定されたコマンドが実行された時、ルールによって追加のコマンドが実行されるということです。その他にも、INSTEADルールによって指定されたコマンドを他のコマンドに置き換えたり、まったくコマンドを実行しないようにすることも可能です。ルールはSQLビューを実装するためにも使われます。重要なのは、ルールとは実際にコマンドを変換する仕組み、言い換えれば、コマンドのマクロであることです。ルールによる変換はコマンドの実行前に発生します。各物理行を個別に操作したい場合、ルールではなくトリガを使用する方が良いでしょう。ルールシステムについての詳細は、第38章に記載されています。SELECTルールは、条件を持たないINSTEADルールでなければなりません。SELECTルールが持つアクションは、単独のSELECTコマンドのみで構成される必要があります。SELECTルールを使えば、実質的にテーブルをビューにすることができます。このビューでは、元のテーブルの内容ではなく、ルールに含まれるSELECTコマンドが返す行が、ビューの内容として提示されます。VIEWコマンドを使用する方をお勧めします。DELETEルールを必要に応じて定義し、ビューに対する更新操作を他のテーブルに対する適切な更新操作に置換することで、更新可能なビューという実在しないオブジェクトを作成することができます。RETURNINGなどをサポートしたければ、これらのルールに適切なRETURNING句を確実につけてください。複雑なビューの更新に条件付きルールを使用しようとする場合、落とし穴があります。そのビューに許可するそれぞれの操作に、条件を持たないINSTEADルールを用意する必要があることです。ルールが条件付きであったり、INSTEADでない場合、システムは更新操作を拒否します。その場合、システムが、場合によっては、ビューのダミーテーブルに対する操作になる可能性があるとみなすからです。NOTHINGルールを追加し、ダミーテーブルに対する更新は呼び出されないことをシステムに明示します。条件付きルールには、INSTEADと指定しないようにします。NOTHINGアクションにルールに含まれるアクションが追加されます。(しかし現在、この方法ではRETURNING問い合わせのサポートがうまく動作しません。VIEW参照)は、更新可能とするためにユーザ作成のルールを必要としません。明示的なルールを作成することもできますが、自動更新による変形は明示的なルールよりも通常高速です。TRIGGER参照)を使うことです。パラメータname作成するルールの名前です。この名前は、同じテーブルの他のルールとは異なる名前にする必要があります。同一テーブルにイベントの種類が同じルールが複数あった場合、ルール名の順番(アルファベット順)に適用されます。eventイベントとは、SELECT、INSERT、UPDATE、DELETEのいずれかです。table_nameルールを適用するテーブルまたはビューの名前です(スキーマ修飾名も可)。condition任意のSQL条件式です(boolean型を返します)。条件式では、NEWおよびOLD以外のテーブルは参照できません。集約関数を含めることもできません。INSTEADINSTEADは、元のコマンドの代わりにこのコマンドが実行されることを示します。ALSOALSOは元のコマンドに加えてこのコマンドが実行されることを示します。ALSOもINSTEADも指定されなかった場合、ALSOがデフォルトです。commandルールのアクションを構成する単一または複数のコマンドです。有効なコマンドは、SELECT、INSERT、UPDATE、DELETE、NOTIFYです。conditionとcommandの内部では、対象とするテーブルの値を参照するために、特別なテーブル名NEWとOLDを使用できます。UPDATEルールで有効です。挿入または更新される新しい行を参照します。DELETEルールで有効です。更新または削除される既存の行を参照します。注釈テーブルにルールを定義する、または、そのルールを変更するためには所有者でなければなりません。上のINSERT、UPDATE、DELETEルールでは、RETURNING句を追加して、ビューの列を返すことができます。RETURNINGコマンドによって呼び出された場合、この句は出力を計算することに使用されます。RETURNINGなしでルールが呼び出された場合、ルールのRETURNING句は無視されます。現在の実装では、無条件のINSTEADルールのみがRETURNINGを含むことができます。同一イベント用のすべてのルールの中で多くても1つのRETURNING句を持つことができます。(これにより確実に、結果を計算するために使用されるRETURNING句の候補が1つのみになります。上のRETURNING問い合わせは、利用可能なルールのどれにもRETURNINGが存在しない場合に拒絶されます。ルールの循環は絶対に避けるよう注意してください。下記の2つのルール定義それぞれはPostgreSQLに受け入れられますが、ルールが再帰的に展開されるため、SELECTコマンドが、PostgreSQLにエラーを表示させます。t1;現在、ルールのアクションにNOTIFYコマンドが含まれる場合、NOTIFYコマンドは無条件に実行されます。ルールを適用すべき行が存在しなかったとしても、NOTIFYが発行されます。42という条件に一致する行があってもなくても、UPDATEの際、1つのNOTIFYイベントが送信されます。これは実装上の制限であり、将来のリリースでは修正されるかもしれません。RULEはPostgreSQLの言語拡張で、問い合わせ書き換えシステム全体が言語拡張です。