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 1pDO2P-00014c-At for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 11:03:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDO2N-0008LV-Lp for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2023 11:03:55 +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 1pDO2M-0008LC-G5 for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 11:03:55 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDO2J-00041H-Jc for pgsql-hackers@lists.postgresql.org; Thu, 05 Jan 2023 11:03:53 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 41EF93200A22; Thu, 5 Jan 2023 06:03:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 05 Jan 2023 06:03:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id: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=fm2; t=1672916628; x=1673003028; bh=I pesO362wlrbH27ej2UQBls3WTd2MrODb+7EO0Fccr0=; b=dOXUmEv3Z+8pvjXpT EqUD1GWCj/8jOSibCjy+GTpLsmLHCf1LVnwTl0FOy8/pab99xfShVmpgqtyKm/q6 TGtdIPj6nRIwxqHXw/mCQGjy/y9AJ1m75djC1QkURpt03CPocx6f2zrnTjRobKYC 6pqwJIKqp+pC3I/gg9b9C72m3BoAR0VVfGqNScWbS+HLXW0dQ6Zt6uHpU768oEtM bmes4Re6iKWVJo9FmFYnW5k1MTSEmXOt5YdliCo0RJaf9jcuVtu3uBKzUOsUGtOv EBvKDvWuYFk4I8lQVEArnJhChKhMC+PugATxMFZ/R/FUWaOWMtM6vG5Gl3dHhouQ mp0og== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeekgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeejkeff gfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Jan 2023 06:03:48 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C44CF6D; Wed, 4 Jan 2023 12:57:58 +0100 (CET) Date: Wed, 4 Jan 2023 12:57:58 +0100 From: Alvaro Herrera To: Dean Rasheed Cc: PostgreSQL Hackers Subject: Re: MERGE ... WHEN NOT MATCHED BY SOURCE Message-ID: <20230104115758.2ajc235gphwfe3d6@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 I haven't read this patch other than superficially; I suppose the feature it's introducing is an OK one to have as an extension to the standard. (I hope the community members that are committee members will propose this extension to become part of the standard.) On 2023-Jan-02, Dean Rasheed wrote: > --- a/src/backend/optimizer/prep/preptlist.c > +++ b/src/backend/optimizer/prep/preptlist.c > @@ -157,15 +157,14 @@ preprocess_targetlist(PlannerInfo *root) > /* > * Add resjunk entries for any Vars used in each action's > * targetlist and WHEN condition that belong to relations other > - * than target. Note that aggregates, window functions and > - * placeholder vars are not possible anywhere in MERGE's WHEN > - * clauses. (PHVs may be added later, but they don't concern us > - * here.) > + * than target. Note that aggregates and window functions are not > + * possible anywhere in MERGE's WHEN clauses, but PlaceHolderVars > + * may have been added by subquery pullup. > */ > vars = pull_var_clause((Node *) > list_concat_copy((List *) action->qual, > action->targetList), > - 0); > + PVC_INCLUDE_PLACEHOLDERS); Hmm, is this new because of NOT MATCHED BY SOURCE, or is it something that can already be hit by existing features of MERGE? In other words -- is this a bug fix that should be backpatched ahead of introducing NOT MATCHED BY SOURCE? > @@ -127,10 +143,12 @@ transformMergeStmt(ParseState *pstate, M > */ > is_terminal[0] = false; > is_terminal[1] = false; > + is_terminal[2] = false; I think these 0/1/2 should be replaced by the values of MergeMatchKind. > + /* Join type required */ > + if (left_join && right_join) > + qry->mergeJoinType = JOIN_FULL; > + else if (left_join) > + qry->mergeJoinType = JOIN_LEFT; > + else if (right_join) > + qry->mergeJoinType = JOIN_RIGHT; > + else > + qry->mergeJoinType = JOIN_INNER; One of the review comments that MERGE got initially was that parse analysis was not a place to "do query optimization", in the sense that the original code was making a decision whether to make an outer or inner join based on the set of WHEN clauses that appear in the command. That's how we ended up with transform_MERGE_to_join and mergeUseOuterJoin instead. This new code is certainly not the same, but it makes me a bit unconfortable. Maybe it's OK, though. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/