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 1pJfi5-0002wm-Em for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 19:08: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 1pJfi3-0003OX-TU for pgsql-hackers@arkaria.postgresql.org; Sun, 22 Jan 2023 19:08: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 1pJfi2-0003Ms-NV for pgsql-hackers@lists.postgresql.org; Sun, 22 Jan 2023 19:08:55 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJfhz-0000yX-Mh for pgsql-hackers@lists.postgresql.org; Sun, 22 Jan 2023 19:08:53 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A659C32001FC; Sun, 22 Jan 2023 14:08:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 22 Jan 2023 14:08:48 -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=fm3; t=1674414528; x=1674500928; bh=9 6Z1Gls5rti4w9YWPmB9V0kWL/vf6g5e5hNwq0hpT1E=; b=BNz9aVkTXwDrSDWEZ diLuGKR0yV3QKHFmpYiCCpxNjdR+IuvhBC2p4WrBB9cN8EKv9bkej229DM1QIUtv bydJJp4vpI5QA4tUgyGYu95Ss3FUlnIm7xL2garY4SjveVqNF+rjmyoaq30JYGnH cGc4VdcfUTV84SOTVFe6RYs2aEAnip999cgQToyAM6yJ8HDYBWGIkcohnbceDIbl HacfGnfTITy2i/zGwZzio8Dy7eZdUg3kNSE79+Ojyd+/7mEPy5Kfs7WYSXvmdZ3j xuvrypdPzY0cnwhUwJXUJBm4MtHaVnMUiE+9CYw5XQ3ScU6Inb2+qbpxFt4UmpDs 8SWpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduiedguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 22 Jan 2023 14:08:47 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 3A4D098; Sun, 22 Jan 2023 19:58:39 +0100 (CET) Date: Sun, 22 Jan 2023 19:58:39 +0100 From: Alvaro Herrera To: Dean Rasheed Cc: Vik Fearing , Isaac Morland , PostgreSQL Hackers Subject: Re: MERGE ... RETURNING Message-ID: <20230122185839.3btblknlarddawtj@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 > diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c > new file mode 100644 > index e34f583..aa3cca0 > --- a/src/backend/commands/copy.c > +++ b/src/backend/commands/copy.c > @@ -274,12 +274,6 @@ DoCopy(ParseState *pstate, const CopyStm > { > Assert(stmt->query); > > - /* MERGE is allowed by parser, but unimplemented. Reject for now */ > - if (IsA(stmt->query, MergeStmt)) > - ereport(ERROR, > - errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > - errmsg("MERGE not supported in COPY")); Does this COPY stuff come from another branch where you're adding support for MERGE in COPY? I see that you add a test that MERGE without RETURNING fails, but you didn't add any tests that it works with RETURNING. Anyway, I suspect these small changes shouldn't be here. Overall, the idea of using Postgres-specific functions for extracting context in the RETURNING clause looks acceptable to me. We can change that to add support to whatever clauses the SQL committee offers, when they get around to offering something. (We do have to keep our fingers crossed that they will decide to use the same RETURNING syntax as we do in this patch, of course.) Regarding mas_action_idx, I would have thought that it belongs in MergeAction rather than MergeActionState. After all, you determine it once at parse time, and it is a constant from there onwards, right? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/