CREATE RULE(l)SQL - Language Statements (2002-11-22CREATE RULE(l)
NAME
CREATE RULE - define a new rewrite rule
SYNOPSIS
CREATE [ OR REPLACE ] RULE name AS ON event
TO table [ WHERE condition ]
DO [ INSTEAD ] action
where action can be:
NOTHING
| query
| ( query ; query ... )
INPUTS
name The name of a rule to create. This must be distinct
from the name of any other rule for the same table.
event
Event is one of SELECT, UPDATE, DELETE or INSERT.
table
The name (optionally schema-qualified) of the table or
view the rule applies to.
condition
Any SQL conditional expression (returning boolean).
The condition expression may not refer to any tables
except new and old, and may not contain aggregate
functions.
query
The query or queries making up the action can be any
SQL SELECT, INSERT, UPDATE, DELETE, or NOTIFY
statement.
Within the condition and action, the special table names new
and old may be used to refer to values in the referenced
table. new is valid in ON INSERT and ON UPDATE rules to
refer to the new row being inserted or updated. old is
valid in ON UPDATE and ON DELETE rules to refer to the
existing row being updated or deleted.
OUTPUTS
CREATE RULE
Message returned if the rule is successfully created.
DESCRIPTION
CREATE RULE defines a new rule applying to a specified table
or view. CREATE OR REPLACE RULE will either create a new
Page 1 (printed 3/24/03)
CREATE RULE(l)SQL - Language Statements (2002-11-22CREATE RULE(l)
rule, or replace an existing rule of the same name for the
same table.
The PostgreSQL rule system allows one to define an alternate
action to be performed on inserts, updates, or deletions
from database tables. Rules are used to implement table
views as well.
The semantics of a rule is that at the time an individual
instance (row) is accessed, inserted, updated, or deleted,
there is an old instance (for selects, updates and deletes)
and a new instance (for inserts and updates). All the rules
for the given event type and the given target table are
examined successively (in order by name). If the condition
specified in the WHERE clause (if any) is true, the action
part of the rule is executed. The action is done instead of
the original query if INSTEAD is specified; otherwise it is
done after the original query in the case of ON INSERT, or
before the original query in the case of ON UPDATE or ON
DELETE. Within both the condition and action, values from
fields in the old instance and/or the new instance are
substituted for old.attribute-name and new.attribute-name.
The action part of the rule can consist of one or more
queries. To write multiple queries, surround them with
parentheses. Such queries will be performed in the specified
order. The action can also be NOTHING indicating no action.
Thus, a DO INSTEAD NOTHING rule suppresses the original
query from executing (when its condition is true); a DO
NOTHING rule is useless.
The action part of the rule executes with the same command
and transaction identifier as the user command that caused
activation.
It is important to realize that a rule is really a query
transformation mechanism, or query macro. The entire query
is processed to convert it into a series of queries that
include the rule actions. This occurs before evaluation of
the query starts. So, conditional rules are handled by
adding the rule condition to the WHERE clause of the
action(s) derived from the rule. The above description of a
rule as an operation that executes for each row is thus
somewhat misleading. If you actually want an operation that
fires independently for each physical row, you probably want
to use a trigger not a rule. Rules are most useful for
situations that call for transforming entire queries
independently of the specific data being handled.
RULES AND VIEWS
Presently, ON SELECT rules must be unconditional INSTEAD
rules and must have actions that consist of a single SELECT
Page 2 (printed 3/24/03)
CREATE RULE(l)SQL - Language Statements (2002-11-22CREATE RULE(l)
query. Thus, an ON SELECT rule effectively turns the table
into a view, whose visible contents are the rows returned by
the rule's SELECT query rather than whatever had been stored
in the table (if anything). It is considered better style to
write a CREATE VIEW command than to create a real table and
define an ON SELECT rule for it.
CREATE VIEW [create_view(l)] creates a dummy table (with no
underlying storage) and associates an ON SELECT rule with
it. The system will not allow updates to the view, since it
knows there is no real table there. You can create the
illusion of an updatable view by defining ON INSERT, ON
UPDATE, and ON DELETE rules (or any subset of those that's
sufficient for your purposes) to replace update actions on
the view with appropriate updates on other tables.
There is a catch if you try to use conditional rules for
view updates: there must be an unconditional INSTEAD rule
for each action you wish to allow on the view. If the rule
is conditional, or is not INSTEAD, then the system will
still reject attempts to perform the update action, because
it thinks it might end up trying to perform the action on
the dummy table in some cases. If you want to handle all
the useful cases in conditional rules, you can; just add an
unconditional DO INSTEAD NOTHING rule to ensure that the
system understands it will never be called on to update the
dummy table. Then make the conditional rules non-INSTEAD; in
the cases where they fire, they add to the default INSTEAD
NOTHING action.
NOTES
You must have rule definition access to a table in order to
define a rule on it. Use GRANT and REVOKE to change
permissions.
It is very important to take care to avoid circular rules.
For example, though each of the following two rule
definitions are accepted by PostgreSQL, the select command
will cause PostgreSQL to report an error because the query
cycled too many times:
CREATE RULE "_RETURN" AS
ON SELECT TO emp
DO INSTEAD
SELECT * FROM toyemp;
CREATE RULE "_RETURN" AS
ON SELECT TO toyemp
DO INSTEAD
SELECT * FROM emp;
This attempt to select from EMP will cause PostgreSQL to
Page 3 (printed 3/24/03)
CREATE RULE(l)SQL - Language Statements (2002-11-22CREATE RULE(l)
issue an error because the queries cycled too many times:
SELECT * FROM emp;
Presently, if a rule contains a NOTIFY query, the NOTIFY
will be executed unconditionally --- that is, the NOTIFY
will be issued even if there are not any rows that the rule
should apply to. For example, in
CREATE RULE notify_me AS ON UPDATE TO mytable DO NOTIFY mytable;
UPDATE mytable SET name = 'foo' WHERE id = 42;
one NOTIFY event will be sent during the UPDATE, whether or
not there are any rows with id = 42. This is an
implementation restriction that may be fixed in future
releases.
COMPATIBILITY
SQL92
CREATE RULE is a PostgreSQL language extension. There is no
CREATE RULE statement in SQL92.
Page 4 (printed 3/24/03)
