From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: ahodgson@simkin.ca, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17817: DISABLE TRIGGER ALL on a partitioned table with
 foreign key fails
In-reply-to: <2553512.1677868886@sss.pgh.pa.us>
References: <20230303181735.quhcvh2igowmxbs7@alvherre.pgsql>
 <2553512.1677868886@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 03 Mar 2023 13:41:26 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2614794.1677872014.1@sss.pgh.pa.us>
Date: Fri, 03 Mar 2023 14:33:34 -0500
Message-ID: <2614795.1677872014@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2614795.1677872014%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> I wonder how come this problem took so long to be detected with Ruby on
>> Rails; it's been in released 13.x and 14.x for seven months now.

> Um ... 13.x and 14.x aren't showing the problem, or is there something
> I missed?

Oh!  Running the same test shows that while 12.x through 14.x do not
throw an error, they don't disable the child table's triggers either.

Moreover, we can't apply this fix idea since there is no tgparentid
linkage (or indeed any parent trigger to link to).

It's not hard to see one way to fix it: if the initial call is "for
all triggers", forget about recursing for individual triggers and
instead recursively do a "for all triggers" on the child.  However,
that would be the sort of semantics change that people tend to bitch
about in stable branches, because it'd nuke non-inherited triggers
too.

I'm kind of inclined to leave things alone pre-v15.  I asssume the
existing behavior had been that way all along, or do you have reason
to think it changed recently in those branches?

			regards, tom lane