Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Wed, Apr 10, 2024 at 11:32 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I guess we could. It won't matter because the following code will
>> reject RECORD in any case; but we could save a few cycles by not
>> calling get_expr_result_tupdesc there.

> Indeed. I think it would be better to add this same rule to
> process_function_rte_ref(), or at least write some comments there to
> explain why it is not necessary to check rtfunc->funccolnames while
> other places do.

Wilco. Another thing I was considering, but didn't pull the trigger
on in the draft patch, was to introduce a funcapi.c function on the
order of
get_expr_result_rtfunc(RangeTblFunction *rtfunc, ...)
which would encapsulate applying either BuildDescFromLists or
get_expr_result_type. I didn't do it because I found that the
only places that would want to use it are the two that are correct
already; the places we still need to fix have short-cuts they can
take rather than building an intermediate tupdesc. (The present
bug could be summarized as "the short-cuts still need to pay
attention to the coldeflist".) But the advantage of doing this
anyway is that its header comment would be a natural place to
document this issue and policy. Thoughts?

regards, tom lane