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 1kPN4P-00058d-BB for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2020 09:46:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kPN4O-00077X-9O for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2020 09:46:12 +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 1kPN4O-00077Q-2c for pgsql-hackers@lists.postgresql.org; Mon, 05 Oct 2020 09:46:12 +0000 Received: from wforward3-smtp.messagingengine.com ([64.147.123.22]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kPN4J-0002Do-CR for pgsql-hackers@postgresql.org; Mon, 05 Oct 2020 09:46:10 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailforward.west.internal (Postfix) with ESMTP id 657B9752; Mon, 5 Oct 2020 05:46:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 05 Oct 2020 05:46:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=CicfbcDBRqOHWlSe2P+Ht47/7ZtPO4A6rbbdAq2aL 9U=; b=hSLcx9Tc4SdX2EP8EhJM66fHEJwRnvFCdW1wVplToUnqv9T6LLsIIhw7U 2RGk4WVK/vWjKKvWIb08p6avSRKL2YUryFqzTsUWN2le44SE7l2IDp/xyrI+WXxb 5PUJASO3Wj5NtX3p/UMmscCpUC6ofpc7P+cB1ELzcH/XT8F6pdKDLVvYcP90gwWh 3g/7trr9xRsHMEdprpGG6iTcCAtJw4pK8xkNWLGqKPc1bzpvqBxv/wmtdix57fCk AMvEC8tSY4w9yzaLn3P/FIKATuuH87idJIfDLNxhhgh/B2A/uaPzzogT1I7ZoBPX T6Jvg8/RqsC3w93EQ4JHBF1poMZ+Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedvgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnhguqh hurggurhgrnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpeelffffteffjeefhfehffev keeiteeikedufeffhfehveeilefhtefhgeefudehtdenucffohhmrghinhepvdhnughquh grughrrghnthdrtghomhenucfkphepkeejrddujeejrdeigedrudeludenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvg hnthhrrghuthesvdhnughquhgrughrrghnthdrtghomh X-ME-Proxy: Received: from april.pezone.net (p57b140bf.dip0.t-ipconnect.de [87.177.64.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D906328005A; Mon, 5 Oct 2020 05:46:04 -0400 (EDT) Subject: Re: Support for OUT parameters in procedures To: Pavel Stehule , Andrew Dunstan References: <2b8490fe-51af-e671-c504-47359dc453c5@2ndquadrant.com> <4f733cca-5e07-e167-8b38-05b5c9066d04@2ndQuadrant.com> Cc: pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Mon, 5 Oct 2020 11:46:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-09-29 08:23, Pavel Stehule wrote: > This was an important issue if I remember well.  Passing mandatory NULL > as OUT arguments solves this issue. > I fully agree so OUT arguments are part of the procedure's signature. > Unfortunately, there is another difference > from functions, but I don't think so there is a better solution, and we > should live with it. I think it can work well. This has been committed. > I found one issue. The routine for selecting function or procedure based > on signature should be fixed. > > CREATE OR REPLACE PROCEDURE public.procp(OUT integer) >  LANGUAGE plpgsql > AS $procedure$ > BEGIN >   $1 := 10; > END; > $procedure$ > > DO > $$ > DECLARE n numeric; > BEGIN >   CALL procp(n); >   RAISE NOTICE '%', n; > END; > $$; > ERROR:  procedure procp(numeric) does not exist > LINE 1: CALL procp(n) >              ^ > HINT:  No procedure matches the given name and argument types. You might > need to add explicit type casts. > QUERY:  CALL procp(n) > CONTEXT:  PL/pgSQL function inline_code_block line 4 at CALL This is normal; there is no implicit cast from numeric to int. The same error happens if you call a function foo(int) with foo(42::numeric). > postgres=# create or replace procedure px(anyelement, out anyelement) > as $$ > begin >   $2 := $1; > end; > $$ language plpgsql; > > postgres=# call px(10, null); > ERROR:  cannot display a value of type anyelement > > but inside plpgsql it works > do $$ > declare xx int; > begin >   call px(10, xx); >   raise notice '%', xx; > end; > $$; This might be worth further investigation, but since it happens also with INOUT parameters, it seems orthogonal to this patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services