1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
.pgaw:Help.f.t insert end "CREATE RULE" {bold} " 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, 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 and new.attribute-name.
The action part of the rule executes with the same command and transaction identifier as the user command that caused activation.
" {} "Synopsis" {bold} "
CREATE RULE name
AS ON event
TO object \[ WHERE condition \]
DO \[ INSTEAD \] \[ action | NOTHING \]
" {code} "Inputs" {bold} "
" {} "name" {italic} "
The name of a rule to create.
" {} "event" {italic} "
Event is one of select, update, delete or insert.
" {} "object" {italic} "
Object is either table or table.column.
" {} "condition" {italic} "
Any SQL WHERE clause. new or current can appear instead of an instance variable whenever an instance variable is permissible in SQL.
" {} "action" {italic} "
Any SQL statement. new or current can appear instead of an instance variable whenever an instance variable is permissible in SQL.
" {} "Outputs" {bold} "
" {} "CREATE" {italic} "
Message returned if the rule is successfully created.
" {} "Usage" {bold} "
Make Sam get the same salary adjustment as Joe:
" {} "
create rule example_1 as
on update EMP.salary where current.name = \"Joe\"
do update EMP (salary = new.salary)
where EMP.name = \"Sam\"
" {code} "
At the time Joe receives a salary adjustment, the event will become true and Joe's current instance and proposed new instance are available to the execution routines. Hence, his new salary is \
substituted into the action part of the rule which is subsequently executed. This propagates Joe's salary on to Sam.
Make Bill get Joe's salary when it is accessed:
" {} "
create rule example_2 as
on select to EMP.salary
where current.name = \"Bill\"
do instead
select (EMP.salary) from EMP
where EMP.name = \"Joe\"
" {code} "
Deny Joe access to the salary of employees in the shoe department (current_user returns the name of the current user):
" {} "
create rule example_3 as
on select to EMP.salary
where current.dept = \"shoe\" and current_user = \"Joe\"
do instead nothing
" {code} "
Create a view of the employees working in the toy department.
" {} "
create TOYEMP(name = char16, salary = int4)
create rule example_4 as
on select to TOYEMP
do instead
select (EMP.name, EMP.salary) from EMP
where EMP.dept = \"toy\"
" {code} "
All new employees must make 5,000 or less
" {} "
create rule example_5 as
on insert to EMP where new.salary > 5000
do update newset salary = 5000
" {code} "Notes" {bold} "
A caution about SQL rules is in order. If the same class name or instance variable appears in the event, the condition 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 ...
" {code} "
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 14-1. Example of a circular rewrite rule combination.
" {} "
create rule bad_rule_combination_1 as
on select to EMP
do instead select to TOYEMP
create rule bad_rule_combination_2 as
on select to TOYEMP
do instead select to EMP
" {code} "
This attempt to retrieve from EMP will cause Postgres to crash.
" {} "
select * from EMP
" {code} "
You must have rule definition access to a class in order to define a rule on it. Use GRANT and REVOKE to change permissions.
" {} "Bugs" {bold} "
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 stores 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). "
|
