1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00

Remove bogus assertion about polymorphic SQL function result.

It is possible to reach check_sql_fn_retval() with an unresolved
polymorphic rettype, resulting in an assertion failure as demonstrated
by one of the added test cases.  However, the code following that
throws what seems an acceptable error message, so just remove the
Assert and adjust commentary.

While here, I thought it'd be a good idea to provide some parallel
tests of SQL-function and PL/pgSQL-function polymorphism behavior.
Some of these cases are perhaps duplicative of tests elsewhere,
but we hadn't any organized coverage of the topic AFAICS.

Although that assertion's been wrong all along, it won't have any
effect in production builds, so I'm not bothering to back-patch.

Discussion: https://postgr.es/m/21569.1584314271@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2020-03-17 14:54:46 -04:00
parent 0bc8cebdb8
commit 9d9784c840
5 changed files with 279 additions and 14 deletions

View File

@ -1567,13 +1567,16 @@ check_sql_fn_statements(List *queryTreeList)
* false even when the declared function return type is a rowtype.
*
* For a polymorphic function the passed rettype must be the actual resolved
* output type of the function; we should never see a polymorphic pseudotype
* such as ANYELEMENT as rettype. (This means we can't check the type during
* function definition of a polymorphic function.) If the function returns
* composite, the passed rettupdesc should describe the expected output.
* If rettupdesc is NULL, we can't verify that the output matches; that
* should only happen in fmgr_sql_validator(), or when the function returns
* RECORD and the caller doesn't actually care which composite type it is.
* output type of the function. (This means we can't check the type during
* function definition of a polymorphic function.) If we do see a polymorphic
* rettype we'll throw an error, saying it is not a supported rettype.
*
* If the function returns composite, the passed rettupdesc should describe
* the expected output. If rettupdesc is NULL, we can't verify that the
* output matches; that should only happen in fmgr_sql_validator(), or when
* the function returns RECORD and the caller doesn't actually care which
* composite type it is.
*
* (Typically, rettype and rettupdesc are computed by get_call_result_type
* or a sibling function.)
*
@ -1602,9 +1605,6 @@ check_sql_fn_retval(List *queryTreeList,
bool upper_tlist_nontrivial = false;
ListCell *lc;
/* Caller must have resolved any polymorphism */
AssertArg(!IsPolymorphicType(rettype));
if (resultTargetList)
*resultTargetList = NIL; /* initialize in case of VOID result */