postgres.git / summary / log / commit / refs
commit 60c23ff76b1fdabd7c1adcdb00adfb11c77b04dc
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun Mar 18 19:10:28 2018 +0000
First released in: 11.0, 9.3.23, 9.4.18, 9.5.13, 9.6.9, 10.4
Doc: note that statement-level view triggers require an INSTEAD OF trigger.
If a view lacks an INSTEAD OF trigger, DML on it can only work by rewriting
the command into a command on the underlying base table(s). Then we will
fire triggers attached to those table(s), not those for the view. This
seems appropriate from a consistency standpoint, but nowhere was the
behavior explicitly documented, so let's do that.
There was some discussion of throwing an error or warning if a statement
trigger is created on a view without creating a row INSTEAD OF trigger.
But a simple implementation of that would result in dump/restore ordering
hazards. Given that it's been like this all along, and we hadn't heard
a complaint till now, a documentation improvement seems sufficient.
Per bug #15106 from Pu Qun. Back-patch to all supported branches.
Discussion: https://postgr.es/m/152083391168.1215.16892140713507052796@wrigleys.postgresql.org
doc/src/sgml/ref/create_trigger.sgml | 13 +++++++++++++
doc/src/sgml/trigger.sgml | 12 +++++++++---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
index 9de01d5d58d..58e0a030d7b 100644
--- a/doc/src/sgml/ref/create_trigger.sgml
+++ b/doc/src/sgml/ref/create_trigger.sgml
@@ -405,6 +405,19 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
rows.
</para>
+ <para>
+ Statement-level triggers on a view are fired only if the action on the
+ view is handled by a row-level <literal>INSTEAD OF</literal> trigger.
+ If the action is handled by an <literal>INSTEAD</literal> rule, then
+ whatever statements are emitted by the rule are executed in place of the
+ original statement naming the view, so that the triggers that will be
+ fired are those on tables named in the replacement statements.
+ Similarly, if the view is automatically updatable, then the action is
+ handled by automatically rewriting the statement into an action on the
+ view's base table, so that the base table's statement-level triggers are
+ the ones that are fired.
+ </para>
+
<para>
In <productname>PostgreSQL</productname> versions before 7.3, it was
necessary to declare trigger functions as returning the placeholder
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml
index f579340e48f..acd7e0c8d2b 100644
--- a/doc/src/sgml/trigger.sgml
+++ b/doc/src/sgml/trigger.sgml
@@ -52,15 +52,21 @@
<para>
On views, triggers can be defined to execute instead of
<command>INSERT</command>, <command>UPDATE</command>, or
- <command>DELETE</command> operations. <literal>INSTEAD OF</> triggers
+ <command>DELETE</command> operations.
+ Such <literal>INSTEAD OF</literal> triggers
are fired once for each row that needs to be modified in the view.
It is the responsibility of the
- trigger's function to perform the necessary modifications to the
- underlying base tables and, where appropriate, return the modified
+ trigger's function to perform the necessary modifications to the view's
+ underlying base table(s) and, where appropriate, return the modified
row as it will appear in the view. Triggers on views can also be defined
to execute once per <acronym>SQL</acronym> statement, before or after
<command>INSERT</command>, <command>UPDATE</command>, or
<command>DELETE</command> operations.
+ However, such triggers are fired only if there is also
+ an <literal>INSTEAD OF</literal> trigger on the view. Otherwise,
+ any statement targeting the view must be rewritten into a statement
+ affecting its underlying base table(s), and then the triggers
+ that will be fired are the ones attached to the base table(s).
</para>
<para>
[parent: f1f7a85d8c3e]