# CREATE RULE ## Name CREATE RULE?--?定義一個新重寫規則 ## Synopsis ``` CREATE [ OR REPLACE ] RULE _name_ AS ON _event_ TO _table_name_ [ WHERE _condition_ ] DO [ ALSO | INSTEAD ] { NOTHING | _command_ | ( _command_ ; _command_ ... ) } ``` ## 描述 `CREATE RULE`定義一個適用于特定表或者視圖的新規則。 `CREATE OR REPLACE RULE`要么是創建一個新規則， 要么是替換一個表上的同名規則。 PostgreSQL規則系統允許在更新、插入、 刪除時執行一個其它的預定義動作。簡單的說， 規則就是在指定表上執行指定動作的時候，將導致一些額外的動作被執行。 另外，一個`INSTEAD`規則可以用另外一個命令取代特定的命令， 或者令完全不執行該命令。規則還可以用于實現SQL視圖。 規則實際上只是一個命令轉換機制，或者說命令宏。 這種轉換發生在命令開始執行之前。如果你想要針對每個物理行獨立發生的操作， 那么可能應該使用觸發器而不是規則。有關規則系統的更多信息可以在 [Chapter 38](#calibre_link-472)找到。 目前，`ON SELECT`規則必須是無條件的`INSTEAD` 規則并且必須有一個由單獨一條`SELECT`查詢組成的動作。 因此，一條`ON SELECT`規則有效地把表轉成視圖， 它的可見內容是規則的`SELECT` 查詢返回的記錄而不是存儲在表（如果有）中的內容。寫一條 `CREATE VIEW`命令比創建一個表然后在上面定義一條 `ON SELECT`規則的風格要好。 你可以創建一個允許更新的視圖的幻覺，方法是在視圖上定義`ON INSERT`、 `ON UPDATE`、`ON DELETE`規則 (或者滿足你需要的任何上述規則的子集)，用合適的對其它表的更新替換在視圖上更新的動作。 如果打算支持`INSERT RETURNING`之類， 就必須確保在規則的結尾放置恰當的`RETURNING`子句。 如果你想在復雜的視圖更新上使用條件規則，那么這里就有一個補充： 對你希望在視圖上允許的每個動作，你都_必須_ 有一個無條件的`INSTEAD`規則。如果規則是有條件的或者它不是 `INSTEAD`，那么系統仍將拒絕執行更新動作， 因為它認為最終會在視圖的虛擬表上執行這個動作。 如果你想處理條件規則上的所有有用的情況，那只需要增加一個無條件的 `DO INSTEAD NOTHING` 規則確保系統明白它決不會被調用來更新虛擬表就可以了。 然后把條件規則做成非`INSTEAD`；在這種情況下， 如果它們被觸發，那么它們就增加到缺省的`INSTEAD NOTHING` 動作中。（不過這種方法目前不支持`RETURNING`查詢。） > **Note:** 一個足夠簡單可以自動更新的視圖（參閱[CREATE VIEW](#calibre_link-473)） 不需要用戶創建的使其可更新的規則。不過，你可以創建一個明確的規則， 自動更新轉換通常比明確的規則執行的更好。 > > 另一個可替換的價值考慮是使用`INSTEAD OF`觸發器 （參閱[CREATE TRIGGER](#calibre_link-459)）替代規則。 ## 參數 `_name_` 創建的規則名。它必須在同一個表上的所有規則名字中唯一。 同一個表上的同一個事件類型的規則是按照字母順序運行的。 `_event_` `SELECT`、`INSERT`、 `UPDATE`、`DELETE`事件之一。 `_table_name_` 規則作用的表或者視圖的名字(可以有模式修飾)。 `_condition_` 任意返回`boolean`的SQL條件表達式。 條件表達式除了引用`NEW`和`OLD`之外不能引用任何表， 并且不能有聚集函數。 `INSTEAD` `INSTEAD`指示使用該命令_代替_最初的命令。 `ALSO` `ALSO`指示該命令應該在最初的命令執行之后 _一起_執行。 如果既沒有聲明`ALSO`也沒有聲明`INSTEAD`， 那么`ALSO`是缺省。 `_command_` 組成規則動作的命令。有效的命令是`SELECT`、 `INSERT`、`UPDATE`、 `DELETE`、`NOTIFY`語句之一。 在`_condition_`和 `_command_`里， 特殊的表名字`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`子句， 而且在同一個事件內的所有規則中最多只能有一個`RETURNING`子句。 這樣就確保只有一個`RETURNING`子句可以用于計算結果。 如果在任何有效規則中都不存在`RETURNING`子句， 該視圖上的`RETURNING`查詢將被拒絕。 有一件很重要的事情是要避免循環規則。比如，盡管下面兩條規則定義都是 PostgreSQL可以接受的，但其中一條的 `SELECT`命令會導致PostgreSQL 報告一條錯誤信息，因為該查詢循環了太多次： ``` CREATE RULE "_RETURN" AS ON SELECT TO t1 DO INSTEAD SELECT * FROM t2; CREATE RULE "_RETURN" AS ON SELECT TO t2 DO INSTEAD SELECT * FROM t1; SELECT * FROM t1; ``` 目前，如果一個規則包含一個`NOTIFY`命令， 那么該`NOTIFY`命令將被無條件執行，也就是說， 即使規則不施加到任何行上面，該`NOTIFY`也會被執行。 比如，在 ``` CREATE RULE notify_me AS ON UPDATE TO mytable DO ALSO NOTIFY mytable; UPDATE mytable SET name = 'foo' WHERE id = 42; ``` 里，一個`NOTIFY`事件將在`UPDATE` 的時候發出，不管是否有滿足`id = 42`條件的行。 這是一個實現的限制，將來的版本應該修補這個毛病。 ## 兼容性 `CREATE RULE`是PostgreSQL 語言的擴展，整個規則重寫系統都是如此。 ## 又見 [ALTER RULE](#calibre_link-474), [DROP RULE](#calibre_link-475)