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

On Wed, Apr 10, 2024 at 10:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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?

Do you think we can have a parameter in the new get_expr_result_rtfunc()
function to indicate whether we want to build an intermediate tupdesc
when we have a coldeflist? Then we can set it to true in the two places
that are correct already, and set it to false at the places we need to
fix. But I'm not sure if including such a new parameter would be an
improvement or just make it worse.

Thanks
Richard