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 1s7IR4-004oEO-MK for pgsql-bugs@arkaria.postgresql.org; Wed, 15 May 2024 17:29:04 +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 1s7IR4-00336e-Oj for pgsql-bugs@arkaria.postgresql.org; Wed, 15 May 2024 17:29:02 +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 1s7IR4-00336U-GP for pgsql-bugs@lists.postgresql.org; Wed, 15 May 2024 17:29:02 +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.94.2) (envelope-from ) id 1s7IR2-000MiQ-2C for pgsql-bugs@lists.postgresql.org; Wed, 15 May 2024 17:29:01 +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 44FHSvAu1800944; Wed, 15 May 2024 13:28:57 -0400 From: Tom Lane To: Dmitry Dolgov <9erthalion6@gmail.com> cc: drewk@cockroachlabs.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18463: Possible bug in stored procedures with polymorphic OUT parameters In-reply-to: <20240515143506.pln5mzipy7iwa45i@ddolgov.remote.csb> References: <18463-f8cd77e12564d8a2@postgresql.org> <20240514151843.yvq3wlt7n2kechv5@ddolgov.remote.csb> <1124184.1715706026@sss.pgh.pa.us> <1341220.1715715337@sss.pgh.pa.us> <1631943.1715731231@sss.pgh.pa.us> <20240515143506.pln5mzipy7iwa45i@ddolgov.remote.csb> Comments: In-reply-to Dmitry Dolgov <9erthalion6@gmail.com> message dated "Wed, 15 May 2024 16:35:06 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1800942.1715794137.1@sss.pgh.pa.us> Date: Wed, 15 May 2024 13:28:57 -0400 Message-ID: <1800943.1715794137@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dmitry Dolgov <9erthalion6@gmail.com> writes: > I'm now curious why it is different for functions, when creating one > with an INOUT ANYELEMENT argument and record return type will error out. > Disabling the corresponding ereport check in CreateFunction seems to > produce a function that works in the similar way as the procedure in > this thread. Are those type of functions incorrect in some way? With procedures, there's no explicit RETURNS clause; we just automatically fill RECORD into prorettype because (a) we gotta put something and (b) that's the right thing anyway if there's multiple OUT parameters. Arguably it's not wrong for a single output parameter, either, since CALL will return a tuple in that case too. I think it might've been better to put VOID for the case of zero output parameters, since CALL doesn't return a zero-column tuple in that case. But that ship's sailed, and it's not worth quibbling about. We do this differently for functions: if there's exactly one output parameter, that is the function result, so prorettype has to match. If we were to allow RETURNS RECORD with a single output parameter, I think that'd have to mean that we return a one-column tuple containing that parameter value. That's not implemented, and I have doubts that it'd be useful. It'd certainly be a bit inefficient. regards, tom lane