From 5b648388b832620af403ad9cafae04eee46bd49f Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Wed, 31 Jan 2018 17:00:17 -0500 Subject: [PATCH] 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 5971d21240..202610a6fe 100644 --- a/doc/src/sgml/ref/create_trigger.sgml +++ b/doc/src/sgml/ref/create_trigger.sgml @@ -501,9 +501,10 @@ UPDATE OF column_name1 [, column_name2 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 REFERENCING clause, then before and after images of rows are visible from all affected partitions or child tables. -- 2.40.0