postgres.git / summary / log / commit / refs

commit    5b648388b832620af403ad9cafae04eee46bd49f
Author:   Bruce Momjian <bruce@momjian.us>
Date:     Wed Jan 31 22:00:17 2018 +0000
First released in: 11.0, 10.2

    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


 doc/src/sgml/ref/create_trigger.sgml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
index 5971d21240b..202610a6fed 100644
--- a/doc/src/sgml/ref/create_trigger.sgml
+++ b/doc/src/sgml/ref/create_trigger.sgml
@@ -501,9 +501,10 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
 
   <para>
    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,
-   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
    named by a <literal>REFERENCING</literal> clause, then before and after
    images of rows are visible from all affected partitions or child tables.


[parent: 19eb7f84e75f]