database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Fix rule rewriter so that new ordering of ON INSERT actions applies

Browse Source 
in cases of qualified rules as well as unqualified ones.  Tweak rules
test to avoid cluttering output with dummy SELECT results.  Update
documentation to match code.
This commit is contained in:
Tom Lane
2001-07-09 23:50:32 +00:00
parent 4fe42dfbc3
commit cb052e0bf1
5 changed files with 56 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/src/sgml/ref/create_rule.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.23 2001/05/27 09:59:27 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.24 2001/07/09 23:50:31 tgl Exp $
Postgres documentation
-->
@ -167,7 +167,8 @@ CREATE
<replaceable class="parameter">action</replaceable> part of the rule is
executed. The <replaceable class="parameter">action</replaceable> is
done instead of the original query if INSTEAD is specified; otherwise
it is done before the original query is performed.
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 <replaceable class="parameter">condition</replaceable>
and <replaceable class="parameter">action</replaceable>, values from
fields in the old instance and/or the new instance are substituted for

22
doc/src/sgml/rules.sgml
View File

@ -1,3 +1,5 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.14 2001/07/09 23:50:32 tgl Exp $ -->
<Chapter Id="rules">
<Title>The <ProductName>Postgres</ProductName> Rule System</Title>
@ -1014,6 +1016,16 @@
for a rule with one action.
</Para>
<Para>
For ON INSERT rules, the original query (if not suppressed by INSTEAD)
is done before any actions added by rules. This allows the actions to
see the inserted row(s). But for ON UPDATE and ON
DELETE rules, the original query is done after the actions added by rules.
This ensures that the actions can see the to-be-updated or to-be-deleted
rows; otherwise, the actions might do nothing because they find no rows
matching their qualifications.
</Para>
<Para>
The parsetrees generated from rule actions are thrown into the
rewrite system again and maybe more rules get applied resulting
@ -1022,8 +1034,8 @@
or another resultrelation. Otherwise this recursive process will end up in a loop.
There is a compiled in recursion limit of currently 10 iterations.
If after 10 iterations there are still update rules to apply the
rule system assumes a loop over multiple rule definitions and aborts the
transaction.
rule system assumes a loop over multiple rule definitions and reports
an error.
</Para>
<Para>
@ -1262,10 +1274,8 @@
</Para>
<Para>
It is important, that the original parsetree is executed last.
The <ProductName>Postgres</ProductName> "traffic cop" does
a command counter increment between the execution of the two
parsetrees so the second one can see changes made by the first.
Here we can see why it is important that the original parsetree is
executed last.
If the UPDATE would have been executed first, all the rows
are already set to zero, so the logging INSERT
would not find any row where 0 != shoelace_data.sl_avail.