Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA01572; Fri, 2 Apr 93 20:02:47 -0800
Message-Id: <9304030402.AA01572@postgres.Berkeley.EDU>
From: jeffrey@iti.gov.sg (Jeffrey Goh)
Subject: Re: big dumps from rewrites
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of "Fri, 02 Apr 1993 00:26:22 PST."
             <9304020826.AA25108@postgres.Berkeley.EDU> 
Date: Sat, 03 Apr 1993 12:04:29 +0800
Sender: jeffrey@iti.gov.sg


Sigh, the rewrite rule system was _never_ intended to handle circular
rules of the form you have described.  The reason is simply that
rewrite rules can only detect circularity regarding tables and
qualifiers, not indivdual tuples of the table.  That is, we know that if
a retrieve to table emp triggers another retrieve to table emp
then there is a chance that this rule will be self recursive.
However, there is also a chance that the rule will _not_ be self
recursive.  This would be the case if the qualifiers of the
action and the trigger are mutually exclusive.  For example:

	on retrieve to emp where emp.name = "jeff"
	do replace ( current.salary = e1.salary ) where
		e1.name = "mike"

is a trivial example of a rule that would not be self recursive
even though the action actually becomes another retrieve to the
same table.

However, doing logical evaluation of the qualifiers to determine what are
mutually exclusive qualifiers and what are _not_ would mean
having to write a rule solver that muddles around with solving
the qualifiers before even looking at the tuples.  

The alternative would have been to disallow rules that _might_
be self recursive.  I simply decided that this would be too restrictive
and instead put disclaimers that the user better damn well know
not to write self recursive (or mutually recursive) rules. 
The idea then was that rules that were not logically mutually
exclusive should then be defined using the tuple level system.

No flames please,
- jeff