summaryrefslogtreecommitdiff
path: root/doc/src/sgml/ref/create_trigger.sgml
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-03-18 15:10:28 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-03-18 15:10:28 -0400
commit7b544c4e053b93851280ee14da8e3b1049b7347c (patch)
treeb8165562124db0bae7fdac3f7d0e69a725bb571d /doc/src/sgml/ref/create_trigger.sgml
parent59743deca9a19126ad711874b05c88ab6a59fc47 (diff)
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
Diffstat (limited to 'doc/src/sgml/ref/create_trigger.sgml')
-rw-r--r--doc/src/sgml/ref/create_trigger.sgml13
1 files changed, 13 insertions, 0 deletions
diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
index 4bde8150122..42172ea1da2 100644
--- a/doc/src/sgml/ref/create_trigger.sgml
+++ b/doc/src/sgml/ref/create_trigger.sgml
@@ -410,6 +410,19 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
</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
type <type>opaque</>, rather than <type>trigger</>. To support loading