diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-03-17 14:54:46 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-03-17 14:54:46 -0400 |
| commit | 9d9784c840f3ac98eb41d021c981eea0fe1735ed (patch) | |
| tree | ac05be6df6d01eea30cc91b2ad8bd3e51e639fea /src/backend/executor/functions.c | |
| parent | 0bc8cebdb889368abdf224aeac8bc197fe4c9ae6 (diff) | |
| download | postgresql-9d9784c840f3ac98eb41d021c981eea0fe1735ed.tar.gz postgresql-9d9784c840f3ac98eb41d021c981eea0fe1735ed.zip | |
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
Diffstat (limited to 'src/backend/executor/functions.c')
| -rw-r--r-- | src/backend/executor/functions.c | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c index 9b45a8a9a0e..c53aaaca612 100644 --- a/src/backend/executor/functions.c +++ b/src/backend/executor/functions.c @@ -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 */ |