Date: Sun, 28 Jan 2018 15:34:02 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, ian@thepathcentral.com,
	pgsql-docs@postgresql.org,
	Andrew Gierth <andrew@tao11.riddles.org.uk>
Subject: Re: Trigger behaviour not as stated
Message-ID: <20180128203402.GB4380@momjian.us>
References: <20171129193934.27108.30796@wrigleys.postgresql.org>
 <20180124181008.GK17109@momjian.us>
 <20180124220701.GP17109@momjian.us>
 <CAEepm=1cAO8y4dFv_xd=43iP7f4T3A2hYAzjgjQagHtt7H87Fw@mail.gmail.com>
 <28238.1517167118@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline
In-Reply-To: <28238.1517167118@sss.pgh.pa.us>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk


--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Jan 28, 2018 at 02:18:38PM -0500, Tom Lane wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > On Thu, Jan 25, 2018 at 11:07 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> ... The attached patch updates the docs to say
> >> statement-level triggers fire on the "referenced" table, while row-level
> >> triggers fire only on the "affected" table, (vs. all affected tables)
> >> even if they are not referenced in the query.  I would backpatch this to
> >> PG 10.
> 
> > I was trying to convey that, but it does seem a little terse and
> > cryptic.  Your addition of "referenced" and "only" make it clearer.
> 
> Hm, the first part of Bruce's change seems fine, but I think this wording:
> 
>      ...  In contrast,
> !    row-level triggers are fired only on affected partitions or child tables,
> !    even if they are not referenced in the query.
> 
> is still confusing.  How about something like
> 
>      In contrast, row-level triggers are fired for each actual row change,
>      including changes in partitions or child tables that are not directly
>      named in the query.
> 
> Possibly "row operation" would be better than "row change".

Uh, I don't think we want to highlight the statement vs row difference
here but the fact that statement triggers fire on the referenced object
and not on the effected rows.  I have attached an updated patch which I
think is an improvement.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--sm4nu43k4a2Rpi4c
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="trigger.diff"

diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml
new file mode 100644
index a8c0b57..42649d2
*** a/doc/src/sgml/ref/create_trigger.sgml
--- b/doc/src/sgml/ref/create_trigger.sgml
*************** UPDATE OF <replaceable>column_name1</rep
*** 501,509 ****
  
    <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 for its partitions or child tables.  In contrast,
!    row-level triggers are fired for all affected partitions or child tables.
     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.
--- 501,510 ----
  
    <para>
     Modifying a partitioned table or a table with inheritance children fires
!    statement-level triggers directly attached to the referenced table, but not
     statement-level triggers for its partitions or child tables.  In contrast,
!    row-level triggers are fired on the rows in effected partitions or
!    child tables, even if they are not referenced 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.

--sm4nu43k4a2Rpi4c--