From: Tom Lane <tgl@sss.pgh.pa.us>
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: <20240514151843.yvq3wlt7n2kechv5@ddolgov.remote.csb>
References: <18463-f8cd77e12564d8a2@postgresql.org>
 <20240514151843.yvq3wlt7n2kechv5@ddolgov.remote.csb>
Comments: In-reply-to Dmitry Dolgov <9erthalion6@gmail.com>
	message dated "Tue, 14 May 2024 17:18:43 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1124183.1715706026.1@sss.pgh.pa.us>
Date: Tue, 14 May 2024 13:00:26 -0400
Message-ID: <1124184.1715706026@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1124184.1715706026%40sss.pgh.pa.us>
Precedence: bulk

Dmitry Dolgov <9erthalion6@gmail.com> writes:
> On Tue, May 14, 2024 at 06:45:29AM +0000, PG Bug reporting form wrote:
>> CREATE PROCEDURE p(INOUT x ANYELEMENT) LANGUAGE SQL AS $$ SELECT x; $$;
>> CALL p(1);
>> The above example results in an error message "cannot display a value of
>> type anyelement", but I would expect it to succeed and output "1".

I agree that this is a bug.  There are comparable cases in our
regression tests that somehow manage to avoid hitting the bug, but
that looks purely accidental to me.

> After looking at this I've got an impression this type of procedures
> have to be disallowed in interpret_function_parameter_list.

No, it's just an oversight.  If you trace through it you will find
that the called procedure does all the right things and returns a
tuple containing the correct values.  The problem happens at the
very end, where we are trying to display that tuple using a tupdesc
that hasn't had the polymorphic types resolved.  That's clearly
possible, since we must have done it at least once already.

I believe the fault lies with CallStmtResultDesc(), which invokes
build_function_result_tupdesc_t() on the pg_proc tuple and thinks
it's done.  However, build_function_result_tupdesc_t clearly says

 * Note that this does not handle resolution of polymorphic types;
 * that is deliberate.

The other caller that needs to think about this is
internal_get_result_type, and behold it does some fooling about
with resolve_polymorphic_tupdesc.  So that's what's missing here.

It looks like we'd have to teach resolve_polymorphic_tupdesc how
to get argument types out of a CallExpr, so that does not lead
to an entirely trivial fix, but it's surely possible.

Maybe it'd be better to not try to use build_function_result_tupdesc_t
here at all.  It looks to me like the output argument list in the
CallStmt is already fully polymorphically resolved, so we could just
build a tupdesc based on that and probably save a lot of work.

			regards, tom lane