Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tZxPy-00EhMS-1n for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Jan 2025 19:26:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tZxPw-005bA9-Rf for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Jan 2025 19:26:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tZxPw-005b7x-JK for pgsql-bugs@lists.postgresql.org; Mon, 20 Jan 2025 19:26:36 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tZxPu-000bBD-16 for pgsql-bugs@lists.postgresql.org; Mon, 20 Jan 2025 19:26:35 +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 50KJQTWu3077203; Mon, 20 Jan 2025 14:26:29 -0500 From: Tom Lane To: Viktor Remennik cc: "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #18780: Bindings types are lost for complex queries In-reply-to: <761091B0-E053-4C4E-A112-1F7D8E700EEE@notexi.st> References: <18780-bae540b8dbfe4cdc@postgresql.org> <761091B0-E053-4C4E-A112-1F7D8E700EEE@notexi.st> Comments: In-reply-to Viktor Remennik message dated "Mon, 20 Jan 2025 18:30:46 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3077201.1737401189.1@sss.pgh.pa.us> Date: Mon, 20 Jan 2025 14:26:29 -0500 Message-ID: <3077202.1737401189@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Viktor Remennik writes: > private static final String MERGE_QUERY = """ > merge into test as dst > using (select ? as id, > ? as ts, > ? as amount) src > on dst.id=? > when matched then > update > set ts=src.ts, > amount=src.amount > when not matched then > insert ("id", "ts", "amount") > values (src.id, src.ts, src.amount) > """; That is never going to work, and you can complain all you want but we're not going to accept it as a bug. The sub-select has to decide on its output column types before parsing can proceed. There is way too much semantic distance between there and where it might be possible to discover that the output columns are going to be assigned to particular target columns; furthermore, the outer query might have other references to the sub-select's columns that do not provide usable context for resolving their types, or that provide conflicting hints. The only cases like this that we support are insert into sometable values (?) insert into sometable select ? update sometable set somecolumn = ? where there is basically not anything between the unlabeled parameter and its single use as an assignment source. (Even these are undesirably messy internally.) regards, tom lane