Create rule is used to define a new rule.
Here, event is one of select, update, delete or insert. Object is either:
a class name
or
class.column
The from clause, the where clause,
and the action are respectively normal SQL from clauses, where clauses
and collections of SQL commands with the following change:
The semantics of a rule is that at the time an individual
instance is accessed, updated, inserted or deleted, there is a current
instance (for retrieves, updates and deletes) and a new instance (for
updates and appends). If the event specified in the on clause and the
condition specified in the where clause are true for the current instance,
then the action part of the rule is executed. First, however, values
from fields in the current instance and/or the new instance are substituted
for: current.attribute-name
new.attribute-name
The action part of the rule
executes with same command and transaction identifier as the user command
that caused activation.
A note of caution about SQL rules is in order.
If the same class name or instance variable appears in the event, where
clause and the action parts of a rule, they are all considered different
tuple variables. More accurately, new and current are the only tuple variables
that are shared between these clauses. For example, the following two rules
have the same semantics: on update to EMP.salary where EMP.name = "Joe"
do update EMP ( ... ) where ...
on update to EMP-1.salary where EMP-2.name =
"Joe"
do update EMP-3 ( ... ) where ...
Each rule can have the optional tag
instead. Without this tag action will be performed in addition to the
user command when the event in the condition part of the rule occurs.
Alternately, the action part will be done instead of the user command.
In this later case, the action can be the keyword nothing.
When choosing between the rewrite and instance rule systems for a particular rule application, remember that in the rewrite system current refers to a relation and some qualifiers whereas in the instance system it refers to an instance (tuple).
It is very important to note that the rewrite rule system will neither
detect nor process circular rules. For example, though each of the following
two rule definitions are accepted by Postgres, the retrieve command
will cause Postgres to crash: --
--Example of a circular rewrite rule combination.
--
create rule bad_rule_combination_1 is
on select to EMP
do instead
select to TOYEMP
create rule bad_rule_combination_2 is
on select to
TOYEMP
do instead select to EMP
--
--This attempt to retrieve from EMP
will cause Postgres to crash.
--
select * from EMP
You must have rule definition access to a class in order to define a rule on it (see change acl(l) .
create rule example_4 is
on select to TOYEMP
do instead select (EMP.name, EMP.salary) from EMP
where EMP.dept =
"toy"
--
--All new employees must make 5,000 or less
--
create rule example_5
is
on insert to EMP where new.salary > 5000
do update newset salary =
5000
instead rules do not work properly.
The object in a SQL rule cannot be an array reference and cannot have parameters.
Aside from the `oid' field, system attributes cannot be referenced anywhere in a rule. Among other things, this means that functions of instances (e.g., `foo(emp)' where `emp' is a class) cannot be called anywhere in a rule.
The rule system store the rule text and query plans as text attributes. This implies that creation of rules may fail if the rule plus its various internal representations exceed some value that is on the order of one page (8KB).