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 1nm0rG-0003pz-Eo for pgsql-bugs@arkaria.postgresql.org; Tue, 03 May 2022 22:19:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nm0rE-00078T-Of for pgsql-bugs@arkaria.postgresql.org; Tue, 03 May 2022 22:19:00 +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 1nm0rE-00078I-GF for pgsql-bugs@lists.postgresql.org; Tue, 03 May 2022 22:19:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nm0r8-0005OT-2A for pgsql-bugs@postgresql.org; Tue, 03 May 2022 22:18:59 +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 243MIqsZ2234573; Tue, 3 May 2022 18:18:52 -0400 From: Tom Lane To: "David G. Johnston" cc: Daniele Varrazzo , pgsql-bugs Subject: Re: Types pollution with unknown oids and server-side parameters binding In-reply-to: References: <2189979.1651607722@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Tue, 03 May 2022 13:31:08 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2234571.1651616332.1@sss.pgh.pa.us> Date: Tue, 03 May 2022 18:18:52 -0400 Message-ID: <2234572.1651616332@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Tue, May 3, 2022 at 12:55 PM Tom Lane wrote: >> What do you think ought to happen? The same parameter somehow having >> different types in different places? > Based upon: > "When a parameter's data type is not specified or is declared as unknown, > the type is inferred from the context in which the parameter is first > referenced (if possible)." Right ... > The parameter would seem to be first referenced as a timestamp (at least in > parsing order). Actually, if you look at transformUpdateStmt, you'll see the parsing order is WITH, then FROM, then WHERE, then RETURNING, then the targetlist. Some of this is constrained by semantics: we have to do WITH first because it'll define pseudo-tables used in FROM, and we have to do FROM before we can make sense of the rest. We could possibly do the targetlist before WHERE, but any assumption that it works left-to-right is just doomed to failure by the poor consistency of SQL syntax. regards, tom lane