Commit 1cf11129 authored by Bruce Momjian's avatar Bruce Momjian

doc: clearify trigger behavior for inheritance

The previous wording added in PG 10 wasn't specific enough about the
behavior of statement and row triggers when using inheritance.

Reported-by: ian@thepathcentral.com

Discussion: https://postgr.es/m/20171129193934.27108.30796@wrigleys.postgresql.org

Backpatch-through: 10
parent 3b152559
...@@ -501,9 +501,10 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</ ...@@ -501,9 +501,10 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
<para> <para>
Modifying a partitioned table or a table with inheritance children fires Modifying a partitioned table or a table with inheritance children fires
statement-level triggers directly attached to that table, but not statement-level triggers attached to the explicitly named table, but not
statement-level triggers for its partitions or child tables. In contrast, statement-level triggers for its partitions or child tables. In contrast,
row-level triggers are fired for all affected partitions or child tables. row-level triggers are fired on the rows in effected partitions or
child tables, even if they are not explicitly named in the query.
If a statement-level trigger has been defined with transition relations If a statement-level trigger has been defined with transition relations
named by a <literal>REFERENCING</literal> clause, then before and after named by a <literal>REFERENCING</literal> clause, then before and after
images of rows are visible from all affected partitions or child tables. images of rows are visible from all affected partitions or child tables.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment