From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: drewk@cockroachlabs.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18463: Possible bug in stored procedures with polymorphic OUT parameters
Date: Tue, 14 May 2024 13:00:26 -0400
Message-ID: <1124184.1715706026@sss.pgh.pa.us> (raw)
In-Reply-To: <20240514151843.yvq3wlt7n2kechv5@ddolgov.remote.csb>
References: <18463-f8cd77e12564d8a2@postgresql.org>
<20240514151843.yvq3wlt7n2kechv5@ddolgov.remote.csb>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, 9erthalion6@gmail.com, drewk@cockroachlabs.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18463: Possible bug in stored procedures with polymorphic OUT parameters
In-Reply-To: <1124184.1715706026@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox