Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1efk4n-0005xi-Qx for pgsql-docs@arkaria.postgresql.org; Sun, 28 Jan 2018 10:20:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efk4m-0004DR-DJ for pgsql-docs@arkaria.postgresql.org; Sun, 28 Jan 2018 10:20:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1efk4l-0004DH-Vr for pgsql-docs@lists.postgresql.org; Sun, 28 Jan 2018 10:20:40 +0000 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1efk4c-0007MW-PB for pgsql-docs@postgresql.org; Sun, 28 Jan 2018 10:20:39 +0000 Received: by mail-wm0-x244.google.com with SMTP id i186so8739422wmi.4 for ; Sun, 28 Jan 2018 02:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Emb3SPmtxsal8NSpw4h3hfZ5RZGWTlo4LrZ5N4KuuBc=; b=Owq5GWgJRleR4eJY9agEjX7KND0BRWm8eefr3Gu+P3EREsrK2YL1/Ympqn/IwtTL55 7H9BjwiH7Jm31VvRAChUcEINo2BwNNe0FvmMJGRcGIglmS8qizMYqZcjhb5sbCrLSlyG tRyKXyXen/+GtfMPU6tKHIPyh2zxAoz6RIqMyS/WlUZ3M6J48mp4d6H27qwbzNKbnxtC 0CBF4O3+cFkUCZi0NN2ifOlPPTflpzhlwMMBpb52N+RMCcJfOdrPNmU9YwxBAsu1krpi fxOhS1lZ/Xw7bL+5UxCE0hS/4ZRkF5grEJzcZTECV8+sM/32oS6N2peHQJ4sHkJzOwJw YCug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Emb3SPmtxsal8NSpw4h3hfZ5RZGWTlo4LrZ5N4KuuBc=; b=F7NVOlRlUebaZsmOVDtrdc7YiBxDnTNbs2uIygjazcjrCXixVN2trUciBjHFHtra13 GwNo8yUpVuFCj+MzT1JPjPkzJUqZmhZYQwVRVjsQdGxuxS/uQT4/ravph4l48a9HeOvJ vU7UmivZFfxcIQ+M8KlbGHL+H+HfeQ7MWuS+ogy7m6V2d4sxDwdndLqa3RpC661haeQL /WwUM4Bbiffwn2bSz4zevxaCPMlTXLWe2AT7TTzmWohlO3x0xam8irYC134EVFf/PFnV yoLxy/SschajZ/BTSDJm7XaP/ZOw/B64RvR9GoCiqWEWUjvJGEi50IjJtqbylHlDXZQp JvbQ== X-Gm-Message-State: AKwxytd8GpuSvF5CvFvg+1ERbcXibVhtIHX6OfI9899FHOa9Uy63Pi1C sxOxFIHR+URShGx4frjrNQRLhX8HTRtFt4GzTII3rg== X-Google-Smtp-Source: AH8x224Ppvs6hGuwX92VR9Sv55I802RWzto54VqeaAVM3f2+6OS5/mukml2ax5nw+g3kl/byau4K/fvS0elfHV21fUc= X-Received: by 10.28.183.5 with SMTP id h5mr15281127wmf.14.1517134827831; Sun, 28 Jan 2018 02:20:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.203 with HTTP; Sun, 28 Jan 2018 02:19:47 -0800 (PST) In-Reply-To: <20180124220701.GP17109@momjian.us> References: <20171129193934.27108.30796@wrigleys.postgresql.org> <20180124181008.GK17109@momjian.us> <20180124220701.GP17109@momjian.us> From: Thomas Munro Date: Sun, 28 Jan 2018 23:19:47 +1300 Message-ID: Subject: Re: Trigger behaviour not as stated To: Bruce Momjian Cc: ian@thepathcentral.com, pgsql-docs@postgresql.org, Andrew Gierth Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Jan 25, 2018 at 11:07 AM, Bruce Momjian wrote: > On Wed, Jan 24, 2018 at 01:10:08PM -0500, Bruce Momjian wrote: >> On Wed, Nov 29, 2017 at 07:39:34PM +0000, ian@thepathcentral.com wrote: >> > The following documentation comment has been logged on the website: >> > >> > Page: https://www.postgresql.org/docs/10/static/sql-createtrigger.html >> > Description: >> > >> > URL: https://www.postgresql.org/docs/current/static/sql-createtrigger.html >> > >> > Statement: "In contrast, row-level triggers are fired for all affected >> > partitions or child tables." >> > >> > Row-level triggers are not fired on child tables where the trigger ON BEFORE >> > UPDATE | DELETE is on the parent table. Only works on BEFORE INSERT. > > OK, I have some more details on this. First there is the Stackoverflow > report: > > https://stackoverflow.com/questions/47557665/postgresql-on-before-delete-trigger-not-firing-on-a-parent-table-in-an-inheritan > > The report confirms that row-level triggers are fired _only_ on affected > tables (meaning the table that had a row change), not on any table > mentioned _or_ affected. The current wording, added in this commit: > > commit 501ed02cf6f4f60c3357775eb07578aebc912d3a > Author: Andrew Gierth > Date: Wed Jun 28 18:55:03 2017 +0100 > > Fix transition tables for partition/inheritance. > > We disallow row-level triggers with transition tables on child tables. > Transition tables for triggers on the parent table contain only those > columns present in the parent. (We can't mix tuple formats in a > single transition table.) > > Patch by Thomas Munro > > Discussion: https://postgr.es/m/CA%2BTgmoZzTBBAsEUh4MazAN7ga%3D8SsMC-Knp-6cetts9yNZUCcg%40mail.gmail.com > > should be improved. 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. +1 I was trying to convey that, but it does seem a little terse and cryptic. Your addition of "referenced" and "only" make it clearer. -- Thomas Munro http://www.enterprisedb.com