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 1neGri-00041o-I4 for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 13:47:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neGrg-0007bw-B0 for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 13:47:28 +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 1neGrf-0007bn-9P for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 13:47:28 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neGrY-0005OU-0M for pgsql-hackers@postgresql.org; Tue, 12 Apr 2022 13:47:26 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0C45C3201F73; Tue, 12 Apr 2022 09:47:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 12 Apr 2022 09:47:18 -0400 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= fm3; t=1649771236; x=1649857636; bh=tNtHZLmHJ0VycfhvrwtpzKBceiXK nwKT2i0Ui2AreAw=; b=cW70H1k9WtPSUuvstMQ/3hhxaWPGlwVf4ExyhkhwSyk9 obXBiFcWC+YQZNpj7QwTcD6kck38InqwCXX71uBsxxUiZqrue2RnV3pGUTfKykkY XMBA/8NVWE8M3az2ddacIndDN4sFXjB0bhFwWo72TOy30/L9fLkNS3OzfX4zmO9G siB3KAb2i7GvVxjbBnibBMKVqRUm9DyxyY6iZhPPTh5jcVrtfeafXTzJWAGM69tP mGOUMivGjNd+iiJ0AJIX5aQGazF23xJMtJNmROxAA1FCAeIscd+T2Jz6KLYMky7Q g3rZ2bBGSs3cVyxaZfZ38qKILiSNlVuYwNU3QNibAQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekkedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Apr 2022 09:47:12 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D817C2A1C66; Tue, 12 Apr 2022 15:47:08 +0200 (CEST) Date: Tue, 12 Apr 2022 15:47:08 +0200 From: Alvaro Herrera To: Ranier Vilela Cc: Daniel Gustafsson , Peter Eisentraut , Justin Pryzby , Amit Langote , Japin Li , Zhihong Yu , simon.riggs@enterprisedb.co, Tomas Vondra , Daniel Westermann , Erik Rijkers , Jaime Casanova , Andres Freund , PostgreSQL Hackers Subject: Re: support for MERGE Message-ID: <202204121347.2s2p6eed5mv2@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-Apr-02, Ranier Vilela wrote: > Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera > escreveu: > IMHO, actually there are bug here. > ExecGetChildToRootMap is clear, is possible returning NULL. > To discover if the map is NULL, ExecGetChildToRootMap needs to process > "ResultRelInfo *leaf_part_rri". > So, the argument "if the map is NULL, this function should not be called", > is contradictory. I was not explicit enough. I meant "if no map is needed to adjust columns, then this function should not be called". The caller already knows if it's needed or not; it doesn't depend on literally testing 'map'. If somebody mis-calls this function, it would have crashed, yes; but that's a caller bug, not this function's. A few days ago, the community Coverity also complained about this, so I added an Assert that the map is not null, which should silence it. > If the right fix is to return the original list, here is the patch attached. ... for a buggy caller (one that calls it when unnecessary), then yes this would be the correct code -- except that now the caller doesn't know if the returned list needs to be freed or not. So it seems better to avoid accumulating pointless calls to this function by just not coping with them. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." (L. Torvalds)