Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG52y-00050y-1f for pgsql-sql@arkaria.postgresql.org; Wed, 31 May 2017 14:56:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dG52x-0001T3-Cm for pgsql-sql@arkaria.postgresql.org; Wed, 31 May 2017 14:56:27 +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 1dG51x-00082a-2X for pgsql-sql@postgresql.org; Wed, 31 May 2017 14:55:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dG51u-0003HS-8P for pgsql-sql@postgresql.org; Wed, 31 May 2017 14:55:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v4VEtB8c012407; Wed, 31 May 2017 10:55:13 -0400 From: Tom Lane To: Achilleas Mantzios cc: pgsql-sql Subject: Re: Inconsistent/wrong behavior of pg_trigger_depth when used with DEFERRED CONSTRAINTS In-reply-to: <3d1a5143-389c-256a-cda9-44ca002fc606@matrix.gatewaynet.com> References: <3d1a5143-389c-256a-cda9-44ca002fc606@matrix.gatewaynet.com> Comments: In-reply-to Achilleas Mantzios message dated "Mon, 29 May 2017 14:22:37 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12405.1496242511.1@sss.pgh.pa.us> Date: Wed, 31 May 2017 10:55:11 -0400 Message-ID: <12406.1496242511@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org Achilleas Mantzios writes: > I just run into a behavior that I consider wrong. Test case : Hmm ... after looking at this, I'm not sure why you're surprised. In CONSTRAINTS ALL IMMEDIATE mode, when the first invocation of the trigger function does an UPDATE, the ensuing trigger firing occurs at the end of the UPDATE statement. So it occurs while the outer trigger is still active, pg_trigger_depth() returns 2, and all is well. However, when the trigger firing is deferred, that means it's deferred till end of transaction. So the trigger's UPDATE merely queues a trigger firing request to be done later. When the request is serviced, we're not inside the original trigger anymore, so pg_trigger_depth() returns 1, and the trigger queues another request. Lather rinse repeat. In other words, pg_trigger_depth() tells you about the dynamic state of the control stack; it's not a proxy for detecting whether the action that caused the trigger firing was itself done by a trigger. At least not when you're working with deferrable triggers. You might have better luck by testing to see if the update you are thinking of doing would be a no-op. regards, tom lane -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql