Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type
Дата
Msg-id CAApHDvo1mj4GH+8smoiPzftDNxOi1duXJqYd_p9cdXZeT+qxqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-bugs
On Sun, 31 Dec 2023 at 05:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Bug reporting form <noreply@postgresql.org> writes:
> > ERROR:  attribute 1 of type record has wrong type
> > SQL status: 42804
> > Detail: Table has type text, but query expects integer.
>
> Thanks for the report!  Bisecting shows it broke at
> 1349d2790bf48a4de072931c722f39337e72055e is the first bad commit

Yes, thanks for the report, Vojtěch, and for bisecting to find the
breaking commit, Tom.

It looks like the problem is in ExecEvalPreOrderedDistinctMulti(). It
overwrites the tmpcontext's slots but fails to properly restore the
originals again.

The Aggref->presorted == false version of this,
(process_ordered_aggregate_multi()) seems to use the
aggstate->tmpcontext for the same job, so I imagine I must have just
copied that, but just forgot to restore the old slots. It might be
nicer to have a dedicated ExprContext for this, but we've nowhere to
store that in the backbranches as we can't add a new field to that
struct. Maybe something like the attached is ok as a fix.

David

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18264: Table has type text, but query expects integer.attribute 1 of type record has wrong type
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #18259: Assertion in ExtendBufferedRelLocal() fails after no-space-left condition