Re: Properly pathify the union planner - Mailing list pgsql-hackers

From David Rowley
Subject Re: Properly pathify the union planner
Date
Msg-id CAApHDvqYa_1HcUM4TjzKqXxuZCgFuwMXqQWwXvwR7ZoDiAknJA@mail.gmail.com
Whole thread Raw
In response to Re: Properly pathify the union planner  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Properly pathify the union planner
List 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 by date:

Previous
From: Jacob Champion
Date:
Subject: Re: WIP Incremental JSON Parser
Next
From: Justin Pryzby
Date:
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables