diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2024-06-06 15:16:56 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2024-06-06 15:16:56 -0400 |
| commit | 4208f44c9469fa6b105bbb1d1f7ee18b37472860 (patch) | |
| tree | 2918d90439f35c88758352a35a243d25a9f785e3 /src/test | |
| parent | 78fe33742dccc23d4b8a4a1cc7a311e7be0403d1 (diff) | |
| download | postgresql-4208f44c9469fa6b105bbb1d1f7ee18b37472860.tar.gz postgresql-4208f44c9469fa6b105bbb1d1f7ee18b37472860.zip | |
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
Diffstat (limited to 'src/test')
| -rw-r--r-- | src/test/regress/expected/create_procedure.out | 15 | ||||
| -rw-r--r-- | src/test/regress/sql/create_procedure.sql | 9 |
2 files changed, 24 insertions, 0 deletions
diff --git a/src/test/regress/expected/create_procedure.out b/src/test/regress/expected/create_procedure.out index 4758744071f..2f646a02b55 100644 --- a/src/test/regress/expected/create_procedure.out +++ b/src/test/regress/expected/create_procedure.out @@ -185,6 +185,21 @@ CALL ptest6b(1.1, null, null); 1.1 | {1.1} (1 row) +CREATE PROCEDURE ptest6c(inout a anyelement, inout b anyelement) +LANGUAGE SQL +AS $$ +SELECT $1, 1; +$$; +CALL ptest6c(1, null); + a | b +---+--- + 1 | 1 +(1 row) + +CALL ptest6c(1.1, null); -- fails before v13 +ERROR: return type mismatch in function declared to return record +DETAIL: Final statement returns integer instead of numeric at column 2. +CONTEXT: SQL function "ptest6c" during startup -- collation assignment CREATE PROCEDURE ptest7(a text, b text) LANGUAGE SQL diff --git a/src/test/regress/sql/create_procedure.sql b/src/test/regress/sql/create_procedure.sql index 2dfa0ac2fd3..0ba98fe240f 100644 --- a/src/test/regress/sql/create_procedure.sql +++ b/src/test/regress/sql/create_procedure.sql @@ -127,6 +127,15 @@ $$; CALL ptest6b(1, null, null); CALL ptest6b(1.1, null, null); +CREATE PROCEDURE ptest6c(inout a anyelement, inout b anyelement) +LANGUAGE SQL +AS $$ +SELECT $1, 1; +$$; + +CALL ptest6c(1, null); +CALL ptest6c(1.1, null); -- fails before v13 + -- collation assignment |