CREATE RULEは、指定されたテーブルまたはビューに適用される新しいルールを定義します。
説明
CREATE RULEは、指定されたテーブルまたはビューに適用される新しいルールを定義します。 CREATE OR REPLACE RULEは、新しいルールを作成するか、同じテーブルの同じ名前の既存のルールを置き換えます。
PolarDBルールシステムでは、データベーステーブルの挿入、更新、または削除に対して実行される代替アクションを定義できます。 大まかに言えば、ルールは、所与のテーブル上の所与のコマンドが実行されるときに、追加のコマンドを実行させる。 または、INSTEADルールは、特定のコマンドを別のコマンドに置き換えるか、コマンドをまったく実行しないようにすることができます。 ルールは、SQLビューを実装するためにも使用されます。 ルールは実際にはコマンド変換メカニズム、つまりコマンドマクロであることを認識することが重要です。 この変換は、コマンドの実行が開始される前に行われます。 実際に物理行ごとに独立して起動する操作が必要な場合は、ルールではなくトリガーを使用することをお勧めします。
現在、ON SELECTルールはビューにのみアタッチできます。 (1つをテーブルにアタッチすると、テーブルがビューに変換されます。) このようなルールは "_RETURN" という名前でなければならず、無条件のINSTEADルールでなければならず、単一のSELECTコマンドで構成されるアクションを持つ必要があります。 このコマンドは、ビューの表示内容を定義します。 (ビュー自体は基本的にストレージのないダミーテーブルです。) このようなルールを実装の詳細と見なすのが最善です。 ビューはを介して再定義できますが、ルール "_RETURN" を作成または置き換え...使用する方が良いスタイルですビューの作成または交換.
ON INSERT、ON UPDATE、ON DELETEルール (または目的に十分なサブセット) を定義して、ビューの更新アクションを他のテーブルの適切な更新に置き換えることで、更新可能なビューの錯覚を作成できます。 INSERT RETURNINGなどをサポートする場合は、これらの各ルールに適切なRETURNING句を追加してください。
複雑なビューの更新に条件付きルールを使用しようとすると、問題が発生します。ビューで許可するアクションごとに無条件のINSTEADルールが必要です。 ルールが条件付きの場合、またはINSTEADでない場合、システムは更新アクションの実行を拒否します。これは、場合によっては、ビューのダミーテーブルでアクションを実行しようとする可能性があるためです。 条件付きルールのすべての有用なケースを処理する場合は、無条件のDO INSTEAD NOTHINGルールを追加して、ダミーテーブルを更新するために呼び出されないことをシステムが理解できるようにします。 次に、条件付きルールを非INSTEADにします。それらが適用されている場合は、デフォルトのINSTEAD NOTHINGアクションに追加されます。 (ただし、このメソッドは現在、RETURNINGクエリをサポートしていません。)
概要
CREATE [ OR REPLACE] ルール名AS ONイベント
TO table_name [ WHERE条件]
また [| INSTEAD ] { NOTHING | コマンド | (コマンド; コマンド... ) }
ここで、イベントは次のいずれかになります。
SELECT | 挿入 | 更新 | 削除 自動的に更新可能なほど単純なビュー (CREATE viewを参照) では、更新可能にするためにユーザーが作成したルールは必要ありません。 とにかく明示的なルールを作成できますが、自動更新変換は一般に明示的なルールよりも優れています。
考慮に値する別の代替案は、ルールの代わりにINSTEAD OFトリガー (CREATE TRIGGERを参照) を使用することです。
パラメーター
name: 作成するルールの名前。 これは、同じテーブルの他のルールの名前とは異なる必要があります。 同じテーブルと同じイベントタイプの複数のルールがアルファベット順に適用されます。event: イベントは、SELECT、INSERT、UPDATE、DELETEのいずれかです。ON CONFLICT句を含むINSERTは、INSERTまたはUPDATEルールを持つテーブルでは使用できません。 代わりに更新可能なビューを使用することを検討してください。table_name: ルールが適用されるテーブルまたはビューの名前 (スキーマ修飾) 。条件: AnySQL条件式 (ブール値を返す) 。 条件式は、NEWとOLD以外のテーブルを参照できず、集計関数を含めることもできません。INSTEAD:INSTEADは、元のコマンドではなくコマンドを実行することを示します。また:または、元のコマンドに加えてコマンドを実行する必要があることを示します。[また]と[追加]のどちらも指定されていない場合、デフォルトは[また]です。command: ルールアクションを構成する1つまたは複数のコマンド。 有効なコマンドは、SELECT、INSERT、UPDATE、DELETE、またはNOTIFYです。
条件とコマンド内で、特殊なテーブル名NEWとOLDを使用して、参照テーブルの値を参照できます。 NEWは、挿入または更新される新しい行を参照するために、ON INSERTおよびON UPDATEルールで有効です。 OLDは、ON UPDATEおよびON DELETEルールで有効で、更新または削除されている既存の行を参照します。
注
ルールを作成または変更するには、テーブルの所有者である必要があります。
ビューのINSERT、UPDATE、またはDELETEのルールでは、ビューの列を出力するRETURNING句を追加できます。 この句は、ルールがINSERT RETURNING、UPDATE RETURNING、またはDELETE RETURNINGコマンドによってそれぞれトリガーされた場合に出力を計算するために使用されます。 RETURNINGなしのコマンドによってルールがトリガーされた場合、ルールのRETURNING句は無視されます。 現在の実装では、無条件のINSTEADルールのみにRETURNINGを含めることができます。さらに、同じイベントのすべてのルールの中に、最大で1つのRETURNING句があります。 (これにより、結果の計算に使用されるRETURNING句の候補は1つだけになります。) 使用可能なルールにRETURNING句がない場合、ビューに対するRETURNINGクエリは拒否されます。
循環ルールを避けるように注意することは非常に重要です。 たとえば、次の2つのルール定義はそれぞれPostgreSQLで受け入れられますが、SELECTコマンドはルールの再帰的拡張のためにエラーを報告します。
ルール "_RETURN" を作成します
t1にSELECT ON
DO INSTEAD
SELECT * からt2;
ルール "_RETURN" を作成する
選択時にt2
DO INSTEAD
SELECT * からt1;
SELECT * からt1; 現在、ルールアクションがNOTIFYコマンドを含む場合、NOTIFYコマンドは無条件に実行されます。つまり、ルールが適用される行がない場合でも、NOTIFYが発行されます。 たとえば、次のようになります。
mytableにも注意してください。
UPDATE mytable SET name = 'foo' WHERE id = 42; 条件id = 42に一致する行があるかどうかにかかわらず、UPDATE中にNOTIFYイベントが送信されます。 これは、将来のリリースで修正される可能性のある実装制限です。