Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nleQj-0007Gp-I2 for pgsql-docs@arkaria.postgresql.org; Mon, 02 May 2022 22:22:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nleQh-0007LN-Oo for pgsql-docs@arkaria.postgresql.org; Mon, 02 May 2022 22:22:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nleQh-0007LD-E6 for pgsql-docs@lists.postgresql.org; Mon, 02 May 2022 22:22:07 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nleQa-0002iB-Mo for pgsql-docs@lists.postgresql.org; Mon, 02 May 2022 22:22:06 +0000 Received: by mail-ej1-x62c.google.com with SMTP id y3so30199765ejo.12 for ; Mon, 02 May 2022 15:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zQNRd7L/fjnFfY9bKFJQJaOuMR3IMfUbOyEW7At1rog=; b=igE5MQQnYc7wFL+7vmLJsR/013XopGPQmgderZ90xqsBfPePhkfP06WiTX59wmDAyu 15H+TQNZcWSeDcInDfKXE6VgNXJh1Sq1BAyFmBaX0XTHDbslAEd0922bJKJNj2pvoNlF /CdtcQNpg/gVUVyxf4COrp/slFqySk6or0UyKMOLW3yE7AOShPyZhDcrFgkRrFEshKDF 50LB4leI6Zbglo1hxk0DnjG1fV2cYzC7Q4o9rRI2yk4JyC+sAAXrrPP8RULjYffGpZ1c jifEZB1t6KmeSU2j5Xz/04ggeurrvPq8ZrMap/BADasQT1pNgVxa3CZi/cGuRY3J/LQc ZhCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zQNRd7L/fjnFfY9bKFJQJaOuMR3IMfUbOyEW7At1rog=; b=upXhKGEoieRbOcp4HoINePddWxukwd/2l4rf8qRn8UL0GXE7et9JGFh8+eIy7Ry4SH jC6WB2nZ4HMwje10RYFKzb4GIZp6hgH5/UJZ3ewM1F3onrp8p8LJlMhWUAzvirmZqzwY 5Tk9KDp7OQfrUdXDzpHGcOGOQopa03Rw6rqdxhVh1XnEabkAJRoYH8lVkPtrLLj760Qi rhvkXXwnZuz7NGYWQMd8EdxOE2ZRTHyKEbT8wrI5OczvN8l71o4kgnQwTIYGSMHWqnon cXzT2tCgbdNKVtCpuZLeXk177BhNaEzHunkhYRHC6fZt/+ANtIlMb40JRuOAd1Q9jI2Z B+iQ== X-Gm-Message-State: AOAM530UMIpcgHjOiTPbbnOam2RdDAetCFmJjIoY6jMtUlb+jm/xUZdx PQ1s8emR0mwaiVSIEnrt99e5m+8X/AhWERZgCu5TzQBB X-Google-Smtp-Source: ABdhPJxkyadDMiMV11y0vuehVkeoVy5nSVIteU5P6IVlNZwTGL4dMHDMoJckuldpIiJISU6JcsNeYWixfHeQDreVnaA= X-Received: by 2002:a17:907:d22:b0:6f4:8766:2042 with SMTP id gn34-20020a1709070d2200b006f487662042mr862624ejc.259.1651530119068; Mon, 02 May 2022 15:21:59 -0700 (PDT) MIME-Version: 1.0 References: <165151321896.685.16545084197561479198@wrigleys.postgresql.org> In-Reply-To: <165151321896.685.16545084197561479198@wrigleys.postgresql.org> From: "David G. Johnston" Date: Mon, 2 May 2022 15:21:41 -0700 Message-ID: Subject: Re: Clarification of triggers with 'OF column_name' in 'Overview of Trigger Behavior' To: josh.ag@paladin.insure, Pg Docs Content-Type: multipart/alternative; boundary="0000000000001542bb05de0ed277" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001542bb05de0ed277 Content-Type: text/plain; charset="UTF-8" On Mon, May 2, 2022 at 11:14 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/trigger-datachanges.html > Description: > > UPDATE test SET alpha = 5; > > only trigger b2_ab will fire, even though it will update column beta. Column beta eventually changed but you never issued an UPDATE command with beta in the SET clause. The trigger only care about the later. And in fact triggers on a table should never re-issue an actual command against the same table or you end up with infinite triggers. If i > change the declaration of b3_bc by removing the column list or including > column alpha, things work as I expected and b2_ab cascades to b3_bc. > But that isn't how this works. There is no cascading. As soon as the UPDATE query is planned the set of triggers it is going to trigger is basically known and nothing those triggers do individually will change that (aside from raising an error). All you did by changing b3_bc is get it included in the ordered list of triggers that will be executed each time, and only when, an UPDATE command is executed against the named table. If you still believe a meaningful change can be had here a concrete suggestion would be helpful. Otherwise maybe someone takes an interest at some point - but this particular confusion seems extremely rare. David J. --0000000000001542bb05de0ed277 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2022 at 11:14 AM PG Doc comments form <<= a href=3D"mailto:noreply@postgresql.org">noreply@postgresql.org> wro= te:
The following documentation comment has been lo= gged on the website:

Page: https://www.postgresql.org/docs/13/= trigger-datachanges.html
Description:

UPDATE test SET alpha =3D 5;

only trigger b2_ab will fire, even though it will update column beta.

Column beta eventually changed but you never = issued an UPDATE command with beta in the SET clause.=C2=A0 The trigger onl= y care about the later.

And in fact triggers on = a table should never re-issue an actual command against the same table or y= ou end up with infinite triggers.

If i
change the declaration of b3_bc by removing the column list or including column alpha,
things work as I expected and b2_ab cascades to b3_bc.

But that isn't how this works.=C2=A0 There is no ca= scading.=C2=A0 As soon as the UPDATE query is planned the set of triggers i= t is going to trigger is basically known and nothing those triggers do indi= vidually will change that (aside from raising an error).=C2=A0 All you did = by changing b3_bc is get it included in the ordered list of triggers that w= ill be executed each time, and only when, an UPDATE command is executed aga= inst the named table.

If you still believe a mea= ningful change can be had here a concrete suggestion would be helpful.=C2= =A0 Otherwise maybe someone takes an=C2=A0interest at some point - but this= particular confusion seems extremely rare.

David J.

--0000000000001542bb05de0ed277--