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