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

Richard Guo <guofenglinux@gmail.com> writes:
> On Wed, Apr 10, 2024 at 11:32 AM Tom Lane <tgl@sss.pgh.pa.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