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 1oJMNT-00016L-64 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 21:58:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJMNS-0006sy-0x for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 21:58:06 +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 1oJMNR-0006sp-NJ for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 21:58:05 +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 1oJMNL-00053Q-B5 for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 21:58:04 +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 273Lvv7w3245065; Wed, 3 Aug 2022 17:57:57 -0400 From: Tom Lane To: Matthias van de Meent cc: Tomas Vondra , Etsuro Fujita , PostgreSQL Hackers Subject: Re: postgres_fdw: batch inserts vs. before row triggers In-reply-to: References: Comments: In-reply-to Matthias van de Meent message dated "Wed, 03 Aug 2022 23:52:02 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3245063.1659563877.1@sss.pgh.pa.us> Date: Wed, 03 Aug 2022 17:57:57 -0400 Message-ID: <3245064.1659563877@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Matthias van de Meent writes: > I don't have a current version of the SQL spec, but one preliminary > version of SQL:2012 I retrieved via the wiki details that all BEFORE > triggers on INSERT/UPDATE/DELETE statements are all executed before > _any_ of that statements' affected data is modified. > ... > I don't know about the semantics of triggers in the latest SQL > standard versions, but based on that sample it seems like we're > non-compliant on BEFORE trigger behaviour, and it doesn't seem like > it's documented in the trigger documentation. I think we're compliant if you declare the trigger functions as stable (or immutable, but in any case where this matters, I think you'd be lying). They'll then run with the snapshot of the calling query, in which those updates are not yet visible. This is documented somewhere, but maybe not anywhere near triggers. regards, tom lane