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 1pY6gr-00077I-L9 for pgsql-bugs@arkaria.postgresql.org; Fri, 03 Mar 2023 14:47:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pY6gp-0006Y3-PA for pgsql-bugs@arkaria.postgresql.org; Fri, 03 Mar 2023 14:47:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pY6gp-0006XF-GT for pgsql-bugs@lists.postgresql.org; Fri, 03 Mar 2023 14:47:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pY6gm-0004JG-T4 for pgsql-bugs@lists.postgresql.org; Fri, 03 Mar 2023 14:47:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 323ElBIL2416984; Fri, 3 Mar 2023 09:47:11 -0500 From: Tom Lane To: Alvaro Herrera 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: <20230303112144.tzw3yeos2c5w3q6y@alvherre.pgsql> References: <20230303112144.tzw3yeos2c5w3q6y@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Fri, 03 Mar 2023 12:21:44 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2416982.1677854831.1@sss.pgh.pa.us> Date: Fri, 03 Mar 2023 09:47:11 -0500 Message-ID: <2416983.1677854831@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alvaro Herrera writes: > On 2023-Mar-01, Tom Lane wrote: >> It's a reasonable bet that we're trying to look up the child trigger >> using the name of its parent trigger ... but why are we searching by >> name at all, rather than OID? Seems mighty failure-prone. > I have no recollection of this, but we probably didn't have the OID > originally. It may be that simply changing that is enough to solve the > problem. I'll try to have a look later today, but I'm not sure I'll > have time. I can throw together a patch for what I was thinking of. regards, tom lane