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 1nAeZj-0003jg-Tp for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 21:02:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nAeZi-0006VG-GV for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 21:02:30 +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 1nAeZi-0006V7-78 for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 21:02:30 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAeZf-00035i-DJ for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 21:02:29 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 22B015802C4; Thu, 20 Jan 2022 16:02:26 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 20 Jan 2022 16:02:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=hp6F4LTeFJQzMMcbq3vtbmdtxRqN5jkqdG2NvOJYD6o=; b=d1zhqn1E 1xZXIeM02p3rxTEAfHpFCqDQTo1TdcDPTT7RE1oDVykMHVlqVmgH60zMGz1a3OQo VXtCETU9XWXqLuEH4C3QMZn/avZLKKsVsbR7oTLKJJ5SKi1BCmNOCXZyV+1eJWPT 1ln29zy8utS/5xRwCzSJTr92r4sQVHYcJd6hN4j5D7KwVjEEq1KGRkBs+ZoBusnz UsTteV7Ys+/PDooXrJven6cxk0QtUD9Q+hTk3CUHRPLHGj4VOV+cVNP0N9TbmsXo BWryuRFVpqT7I1M4QOyVg+DNXzWCX3ILf2Cit5qbm7eznVA0Ha6G6GGEabuEQujg 7N4AZipllqfoQg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 16:02:25 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id DC95D2A0807; Thu, 20 Jan 2022 18:02:22 -0300 (-03) Date: Thu, 20 Jan 2022 18:02:22 -0300 From: Alvaro Herrera To: Japin Li Cc: Erik Rijkers , Andrew Dunstan , Simon Riggs , Tomas Vondra , Zhihong Yu , Daniel Westermann , Amit Langote , Justin Pryzby , Pavan Deolasee , pgsql-hackers@lists.postgresql.org Subject: Re: support for MERGE Message-ID: <202201202102.ivimvlzzk4rv@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jan-17, Japin Li wrote: > So for NOT MATCHED, we are expected not use the target table columns. > > The code comes from execMerge.c says: > > /* > * Make source tuple available to ExecQual and ExecProject. We don't need > * the target tuple, since the WHEN quals and the targetlist can't refer to > * the target columns. > */ > econtext->ecxt_scantuple = NULL; > econtext->ecxt_innertuple = slot; > econtext->ecxt_outertuple = NULL; > > It will set econtext->ecxt_scantuple to NULL, which leads the crash. Right. So this was broken by the fact that I recently allowed MATCHED actions to target DO NOTHING; previously, only NOT MATCHED actions could do so. So the bug was present, but it wasn't accessible. > Should we setNamespaceVisibilityForRTE() for CMD_NOTHING? I try to set it > and it works as expected. OTOH, the system attributes from target table > also cannot be accessible. I'm not sure the v6 patch how to implement this > limitation. I changed this block so that it depends on whether the clause is MATCHED or NOT MATCHED, rather than the action. I think it was pretty nonsensical for it to be keyed on action type, and it made the code needlessly longer. Thank you! -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "All rings of power are equal, But some rings of power are more equal than others." (George Orwell's The Lord of the Rings)