CREATE RULE
Определяет новое правило перезаписи.
Синтаксис
CREATE [OR REPLACE] RULE <name> AS ON <event>
TO <table_name> [WHERE <condition>]
DO [ALSO | INSTEAD] { NOTHING | <command> | (<command>; <command>
...) }где event может принимать одно из следующих значений:
SELECT | INSERT | UPDATE | DELETEОписание
CREATE RULE определяет новое правило перезаписи, применяемое к указанной таблице или представлению.
CREATE OR REPLACE RULE либо создает новое правило, либо заменяет существующее правило с тем же именем для той же таблицы.
Система правил Greengage DB позволяет определить альтернативное действие, которое будет выполняться при вставках, обновлениях или удалениях в таблицах базы данных.
Правило вызывает выполнение дополнительных или альтернативных команд, когда выполняется заданная команда для заданной таблицы.
Правило INSTEAD может заменить заданную команду другой командой или привести к тому, что команда не будет выполнена вовсе.
Правила также можно использовать для реализации SQL-представлений.
Важно понимать, что правило на самом деле является механизмом преобразования команд, то есть макросом команды.
Преобразование происходит до начала выполнения команды.
Оно не работает независимо для каждой физической строки, как это делает триггер.
Правила 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.
Представление, достаточно простое для автоматического обновления (см. CREATE VIEW), не требует пользовательского правила, чтобы быть обновляемым. Хотя вы все равно можете создать явное правило, автоматическое преобразование обновления обычно будет работать быстрее, чем явное правило.
Параметры
| Параметр | Описание |
|---|---|
name |
Имя создаваемого правила. Должно отличаться от имени любого другого правила для той же таблицы. Несколько правил для одной и той же таблицы и одного и того же типа события применяются в алфавитном порядке имен |
event |
Событие — одно из |
table_name |
Имя (опционально указанное со схемой) таблицы или представления, к которым применяется правило |
condition |
Любое условное SQL-выражение (возвращающее |
INSTEAD |
|
ALSO |
|
command |
Команда или команды, составляющие действие правила.
Допустимые команды: |
Примечания
Чтобы создавать или изменять правила для таблицы, требуется быть ее владельцем.
В правиле для INSERT, UPDATE или DELETE на представлении можно добавить секцию RETURNING, которая выводит столбцы представления.
Эта секция будет использоваться для вычисления результата, если правило срабатывает по команде INSERT RETURNING, UPDATE RETURNING или DELETE RETURNING соответственно.
Когда правило срабатывает по команде без RETURNING, секция RETURNING правила будет проигнорирована.
Текущая реализация допускает наличие RETURNING только в безусловных правилах INSTEAD; кроме того, среди всех правил для одного и того же события может быть не более одной секции RETURNING.
Это гарантирует, что существует только один кандидат RETURNING, который можно использовать для вычисления результата.
Запросы RETURNING к представлению будут отклонены, если ни в одном доступном правиле нет секции RETURNING.
Очень важно избегать циклических правил.
Например, хотя каждое из следующих двух определений правил принимается Greengage DB, команда SELECT приведет к ошибке из-за рекурсивного раскрытия правила.
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;во время UPDATE будет отправлено одно событие NOTIFY, независимо от того, есть ли строки, удовлетворяющие условию id = 42.
Совместимость
CREATE RULE является языковым расширением Greengage DB, как и вся система перезаписи запросов.