pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix failure with SQL-procedure polymorphic output arguments in v 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5fe43d41db599bbe27e8cc75970c093e9c74fa37 Modified Files -------------- src/test/regress/expected/create_procedure.out | 17 +++++++++++++++++ src/test/regress/sql/create_procedure.sql | 9 +++++++++ 2 files changed, 26 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bb331af4aeb714cb63ae0340bd07d7c98576957c Modified Files -------------- src/test/regress/expected/create_procedure.out | 17 +++++++++++++++++ src/test/regress/sql/create_procedure.sql | 9 +++++++++ 2 files changed, 26 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7515982636902ad1e945b4606b02ee706dadb83e Modified Files -------------- src/test/regress/expected/create_procedure.out | 17 +++++++++++++++++ src/test/regress/sql/create_procedure.sql | 9 +++++++++ 2 files changed, 26 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4208f44c9469fa6b105bbb1d1f7ee18b37472860 Modified Files -------------- src/backend/executor/functions.c | 66 +++++++++++++++++++------- src/test/regress/expected/create_procedure.out | 15 ++++++ src/test/regress/sql/create_procedure.sql | 9 ++++ 3 files changed, 74 insertions(+), 16 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9de0ff91a501279af4088e8d6b0885dfd92e31d9 Modified Files -------------- src/test/regress/expected/create_procedure.out | 17 +++++++++++++++++ src/test/regress/sql/create_procedure.sql | 9 +++++++++ 2 files changed, 26 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix failure with SQL-procedure polymorphic output arguments in v @ 2024-06-06 19:17 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-06-06 19:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix failure with SQL-procedure polymorphic output arguments in v12. Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to resolve polymorphic output types and then just throws up its hands and assumes the check will be made at runtime. I think that's true for ordinary functions returning RECORD, but it doesn't happen in CALL, potentially resulting in crashes if the actual output of the SQL procedure's SELECT doesn't match the type inferred from polymorphism. With a little bit of rearrangement, we can use get_call_result_type instead of get_func_result_type and thereby infer the correct types. I'm still unwilling to back-patch all of 913bbd88d, so if the types don't match you'll get an error rather than perhaps silently inserting a cast as v13 and later can. That's consistent with prior behavior though, so it seems fine. Prior to 70ffb27b2, you'd typically get other errors due to other shortcomings of CALL's management of polymorphism. Nonetheless, this is an independent bug. Although there is no bug in v13 and up, it seems prudent to add the test case for this to the newer branches too. It's clearly an under-tested area. Per report from Andrew Bille. Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d88dcdf0fa5b0d6a3b21cea6241fc558e571727e Modified Files -------------- src/test/regress/expected/create_procedure.out | 17 +++++++++++++++++ src/test/regress/sql/create_procedure.sql | 9 +++++++++ 2 files changed, 26 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-06-06 19:17 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v Tom Lane <tgl@sss.pgh.pa.us> 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v Tom Lane <tgl@sss.pgh.pa.us> 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v Tom Lane <tgl@sss.pgh.pa.us> 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v Tom Lane <tgl@sss.pgh.pa.us> 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v Tom Lane <tgl@sss.pgh.pa.us> 2024-06-06 19:17 pgsql: Fix failure with SQL-procedure polymorphic output arguments in v 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