Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Em ter., 25 de mai. de 2021 às 13:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Ranier Vilela <ranier(dot)vf(at)gmail(dot)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