Index for Section RULE

Alphabetical listing for C

Bottom of page

CREATE
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 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 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(5)] 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 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.

Index for Section RULE

Alphabetical listing for C

Top of page