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 1n9c98-0003x4-5r for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Jan 2022 00:14:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n9c95-0003RO-4h for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Jan 2022 00:14:43 +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 1n9c94-0003Qk-Ro for pgsql-hackers@lists.postgresql.org; Tue, 18 Jan 2022 00:14:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n9c91-0004Qd-A4 for pgsql-hackers@postgresql.org; Tue, 18 Jan 2022 00:14:41 +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 20I0EYhA163711; Mon, 17 Jan 2022 19:14:34 -0500 From: Tom Lane To: Justin Pryzby cc: Alvaro Herrera , pgsql-hackers@postgresql.org, Amit Langote Subject: Re: \d with triggers: more than one row returned by a subquery used as an expression In-reply-to: <20220118000824.GC14051@telsasoft.com> References: <20211217154356.GJ17618@telsasoft.com> <20211222210308.GD17618@telsasoft.com> <152507.1642456920@sss.pgh.pa.us> <20220118000824.GC14051@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Mon, 17 Jan 2022 18:08:24 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <163709.1642464874.1@sss.pgh.pa.us> Date: Mon, 17 Jan 2022 19:14:34 -0500 Message-ID: <163710.1642464874@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Justin Pryzby writes: > On Mon, Jan 17, 2022 at 05:02:00PM -0500, Tom Lane wrote: >> ISTM the real problem is the assumption that only related triggers could >> share a tgname, which evidently isn't true. I think this query needs to >> actually match on tgparentid, rather than taking shortcuts. > I don't think that should be needed - tgparentid should match > pg_partition_ancestors(). Uh, what? tgparentid is a trigger OID, not a relation OID. > Is there any reason why WITH ORDINALITY can't work ? > This is passing the smoke test. How hard did you try to break it? It still seems to me that this can be fooled by an unrelated trigger with the same tgname. regards, tom lane