CVSROOT:	/home/projects/pgsql/cvsroot
Module name:	pgsql
Changes by:	wieck@hub.org	01/07/06 09:40:47

Modified files:
	src/backend/rewrite: rewriteHandler.c 

Log message:
	Fire rule actions ON INSERT after original statement (if not INSTEAD).
	
	Jan


Fri, 6 Jul 2001 09:40:47 -0400 (EDT)
Jan Wieck <wieck@hub.org>
pgsql/src/backend/rewrite rewriteHandler.c

TODO updated.

> CVSROOT:	/home/projects/pgsql/cvsroot
> Module name:	pgsql
> Changes by:	wieck@hub.org	01/07/06 09:40:47
> 
> Modified files:
> 	src/backend/rewrite: rewriteHandler.c 
> 
> Log message:
> 	Fire rule actions ON INSERT after original statement (if not INSTEAD).
> 	
> 	Jan
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 6 Jul 2001 14:23:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pgsql/src/backend/rewrite rewriteHandler.c
Jan Wieck <wieck@hub.org> writes:
> 	Fire rule actions ON INSERT after original statement (if not INSTEAD).

It seems to me that this change of ordering should apply to
qual_products (ie, original statement with negation of a conditional
INSTEAD rule's condition) as well as to the unvarnished original
statement in the non-INSTEAD case.  Otherwise it's just about impossible
to give a coherent statement of what the behavior is.

However, when I tried making that change, a whole bunch of differences
popped up in the rules regression test.  They seemed to come from this
example:

create rule rtest_nothn_r1 as on insert to rtest_nothn1
	where new.a >= 10 and new.a < 20 do instead (select 1);

In the old regime, the SELECT got done before the INSERT, so psql throws
away the SELECT result and you see no output.  In the new regime, the
SELECT gets done last and you see its output.  What might be even more
confusing to newbies, you see SELECT output of zero rows when the rule's
WHERE condition fails (since the select is done anyway, but with a false
condition).

My feeling is that I should make the change and adjust the rule test's
expected output (probably by changing this rule to DO INSTEAD NOTHING).
Comments?

			regards, tom lane

Fri, 06 Jul 2001 14:29:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Rule action ordering