pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix handling of polymorphic output arguments for procedures. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/f535f350c1f9b5a9c4f10583992576c3af505275 Modified Files -------------- src/backend/commands/functioncmds.c | 28 +++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++++++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++++++++++++++++ src/test/regress/sql/create_procedure.sql | 18 ++++++++++++++ 5 files changed, 144 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8e0e99972ad92cc128c18bc6af41ef0e4d89e7ae Modified Files -------------- src/backend/commands/functioncmds.c | 28 +++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++++++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++++++++++++++++ src/test/regress/sql/create_procedure.sql | 18 ++++++++++++++ 5 files changed, 144 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c40e78d239a8f7b8a3b6fd180b6e642e269dec5f Modified Files -------------- src/backend/commands/functioncmds.c | 28 +++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++++++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++++++++++++++++ src/test/regress/sql/create_procedure.sql | 18 ++++++++++++++ 5 files changed, 144 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/525bd1620e9ba6b9327cc8ad420ad0352965b2c7 Modified Files -------------- src/backend/commands/functioncmds.c | 28 +++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++++++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++++++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++++++++++++++++ src/test/regress/sql/create_procedure.sql | 18 ++++++++++++++ 5 files changed, 144 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e85f641b2b527255f1a66bbcce46071da9434c42 Modified Files -------------- src/backend/commands/functioncmds.c | 73 ++++++++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++ src/test/regress/sql/create_procedure.sql | 18 +++++++ 5 files changed, 189 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix handling of polymorphic output arguments for procedures. @ 2024-05-15 00:19 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-05-15 00:19 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d8a2@postgresql.org Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/70ffb27b2349441b6a62b41338ac19aadb619151 Modified Files -------------- src/backend/commands/functioncmds.c | 73 ++++++++++++++++++++++++++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++++++++++++ src/pl/plpgsql/src/sql/plpgsql_call.sql | 30 +++++++++++ src/test/regress/expected/create_procedure.out | 34 ++++++++++++ src/test/regress/sql/create_procedure.sql | 18 +++++++ 5 files changed, 189 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-05-15 00:19 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us> 2024-05-15 00:19 pgsql: Fix handling of polymorphic output arguments for procedures. Tom Lane <tgl@sss.pgh.pa.us>
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