Unix/Linux Go Back    

RedHat 9 (Linux i386) - man page for create_rule (redhat section 7)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

CREATE RULE(7)				   SQL Commands 			   CREATE RULE(7)

       CREATE RULE - define a new rewrite rule

       CREATE [ OR REPLACE ] RULE name AS ON event
	   TO table [ WHERE condition ]
	   DO [ INSTEAD ] action

       where action can be:

       | query
       | ( query ; query ... )

       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.

	      Any SQL conditional expression (returning boolean).  The condition  expression  may
	      not  refer  to  any  tables except new and old, and may not contain aggregate func-

       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.

	      Message returned if the rule is successfully created.

       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 sup-
       presses 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,  condi-
       tional 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 inde-
       pendently 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.

       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

       CREATE  VIEW [create_view(7)] creates a dummy table (with no underlying storage) and asso-
       ciates 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  suffi-
       cient 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 under-
       stands 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

       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:

	   ON SELECT TO emp
	    SELECT * FROM toyemp;

	   ON SELECT TO toyemp
	    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.

       CREATE  RULE  is  a  PostgreSQL	language extension.  There is no CREATE RULE statement in

SQL - Language Statements		    2002-11-22				   CREATE RULE(7)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 06:29 PM.