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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF
Дата
Msg-id 330608.1712893609@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF  (Richard Guo <guofenglinux@gmail.com>)
Список pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes:
> On Thu, Apr 11, 2024 at 10:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I did think about that, but it seems mighty weird.  The semantics of
>> the flag would have to be something like "I want a tupdesc when the
>> result type is COMPOSITE, but not when it's RECORD", which seems
>> rather arbitrary.

> Indeed.

I did actually spend some time today trying to code that up, to see
what it would look like.  The attempt failed though, because there
are existing cases in which get_expr_result_type() returns
TYPEFUNC_RECORD, so we can't use that result code as a positive
indicator that "this RTE has a coldeflist".  In a green field
we could invent another TYPEFUNC_XXX code, but that's not a
back-patchable idea.  So the new function would need some independent
indicator that it saw a coldeflist, and at that point there's
basically nothing we're hiding from the callers.

>> Perhaps it'd be sufficient to add a note to the header comment of
>> get_expr_result_type warning about when not to use it.

> Works for me.

OK, barring other objections I'll push forward on that basis.

            regards, tom lane



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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: BUG #18422: Assert in expandTupleDesc() fails on row mismatch with additional SRF
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #18426: Canceling vacuum while truncating a relation leads to standby PANIC