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

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF
Дата
Msg-id CAMbWs4_QgZogwYUgXb=7K_GQ-w2JC3JxONZygkQiXBu11CyXCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs

On Wed, Apr 10, 2024 at 10:16 PM Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Re: FSM Corruption (was: Could not read block at end of the relation)
Следующее
От: Devrim Gündüz
Дата:
Сообщение: Re: BUG #18427: RPM postgis33_15-3.3.6-3PGDG.rhel9.x86_64.rpm not signed