Re: Properly pathify the union planner

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Properly pathify the union planner
Дата
Msg-id CAApHDvqYa_1HcUM4TjzKqXxuZCgFuwMXqQWwXvwR7ZoDiAknJA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Properly pathify the union planner  (Alexander Lakhin <exclusion@gmail.com>)
Ответы Re: Properly pathify the union planner  (Richard Guo <guofenglinux@gmail.com>)
Список pgsql-hackers
On Wed, 27 Mar 2024 at 06:00, Alexander Lakhin <exclusion@gmail.com> wrote:
> SELECT count(*) FROM (
>    WITH q1(x) AS (SELECT 1)
>    SELECT FROM q1 UNION SELECT FROM q1
> ) qu;
>
> TRAP: failed Assert("lg != NULL"), File: "planner.c", Line: 7941, PID: 1133017

Thanks for finding that.

There's something weird going on with the UNION child subquery's
setOperations field. As far as I understand, and from reading the
existing comments, this should only be set for the top-level union.

Because this field is set, it plans the CTE thinking it's a UNION
child and breaks when it can't find a SortGroupClause for the CTE's
target list item.

I'll keep digging. As far as I see the setOperations field is only set
in transformSetOperationStmt(). I'm guessing we must be doing a
copyObject() somewhere and accidentally picking up the parent's
setOperations.

David



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

Предыдущее
От: Jacob Champion
Дата:
Сообщение: Re: WIP Incremental JSON Parser
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables