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 1uk1iz-00EpFg-L0 for pgsql-general@arkaria.postgresql.org; Thu, 07 Aug 2025 14:36:09 +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 1uk1iv-005Bgq-M2 for pgsql-general@arkaria.postgresql.org; Thu, 07 Aug 2025 14:36:05 +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 1uk1iv-005Bge-Aw for pgsql-general@lists.postgresql.org; Thu, 07 Aug 2025 14:36:05 +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 1uk1is-001EbX-1g for pgsql-general@lists.postgresql.org; Thu, 07 Aug 2025 14:36:04 +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 577Ea1Gf1568932; Thu, 7 Aug 2025 10:36:01 -0400 From: Tom Lane To: Dominique Devienne cc: "David G. Johnston" , Pavel Stehule , "pgsql-general@lists.postgresql.org" Subject: Re: CALL and named parameters In-reply-to: References: Comments: In-reply-to Dominique Devienne message dated "Thu, 07 Aug 2025 16:18:43 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1568930.1754577361.1@sss.pgh.pa.us> Date: Thu, 07 Aug 2025 10:36:01 -0400 Message-ID: <1568931.1754577361@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dominique Devienne writes: > I was expecting an error telling me the procedure exists, but the > argument name used in the call didn't. Then it's obvious to me what > mistake I made. If argument names don't participate in the function's > signature, why should they participate in the lookup? Do the lookup > based on name and arg types (and count), that gives you a possible > overload set, which in my second attempt (with a ::name cast) WAS AN > EXACT MATCH for the signature, then give me an error about the > argument name, that does NOT tell me the function doesn't exist. > That's what I would expect. Criticism in the form of a patch is welcome ;-). The problem here is that the matching rules are far more complicated than you seem to think. It's not clear to me that we can definitively say that "we would have had a match except the argument name was wrong". If it is possible to know that, it's quite a few subroutines below where the error is actually issued (see ParseFuncOrColumn -> func_get_detail -> FuncnameGetCandidates -> MatchNamedCall). Maybe there's some fairly painless change that could be made in that rat's nest, but I lack enough caffeine to see it. regards, tom lane