Em ter., 25 de mai. de 2021 às 13:09, Tom Lane <t...@sss.pgh.pa.us> escreveu:
> Ranier Vilela <ranier...@gmail.com> writes: > > Possible pointer TupleDesc rettupdesc used not initialized? > > if (!isNull) at line 4346 taking a true branch, the function > > check_sql_fn_retval at line 4448 can use rettupdesc uninitialized. > > This seems to have been introduced by the SQL-function-body patch. > > After some study, I concluded that the reason we haven't noticed > is that the case is nearly unreachable: check_sql_fn_retval never > consults the rettupdesc unless the function result type is composite > and the tlist length is more than one --- and we eliminated the latter > case earlier in inline_function. > > There is an exception, namely if the single tlist item fails to > be coercible to the output type, but that's hard to get to given > that it'd have been checked while defining the SQL-body function. > I did manage to reproduce a problem after turning off > check_function_bodies so I could create a broken function. > > In any case, inline_function has no business assuming that > check_sql_fn_retval doesn't need a valid value. > > The simplest way to fix this seems to be to move the code that > creates "fexpr" and calls get_expr_result_type, so that we always > do that even for SQL-body cases. We could alternatively use some > other way to obtain a result tupdesc in the SQL-body path; but > creating the dummy FuncExpr node is cheap enough that I don't > think it's worth contortions to avoid doing it. > Following the guidelines, I provided a patch. But I did more than requested, removed redundant variable and reduced the scope of two. vcregress check pass fine. regards, Ranier Vilela
v1_fix_uninitialized_var_clauses.patch
Description: Binary data
