Re: BUG #18859: ERROR: unexpected plan node type: 356

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: splarv(at)ya(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18859: ERROR: unexpected plan node type: 356
Date: 2025-03-21 15:35:03
Message-ID: 1563711.1742571303@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> On 21/3/2025 14:00, Tom Lane wrote:
>> Yeah, I'd just come to the same conclusion. I guess we can make
>> this code look through a Material node as well as Gather.

> Yes, as I see there are no additional corner cases. See the code in
> attachment.

I think actually we want to use the same processing as for Gather,
in particular the check for a Const. That's all about what
setrefs.c will do to the plan tree, and it'll do the same things
to Material as it would to Gather. Since that stanza doesn't
actually do anything that's specific to Gather, the code change
can be as simple as

@@ -8323,7 +8325,7 @@ exec_save_simple_expr(PLpgSQL_expr *expr, CachedPlan *cplan)
((Result *) plan)->resconstantqual == NULL);
break;
}
- else if (IsA(plan, Gather))
+ else if (IsA(plan, Gather) || IsA(plan, Material))
{
Assert(plan->lefttree != NULL &&
plan->righttree == NULL &&

I fixed that, did some cosmetic fooling with the comment
and test case, and pushed it. Thanks for the report,
and for the patch!

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-03-21 15:36:14 Re: BUG #18859: ERROR: unexpected plan node type: 356
Previous Message Richard Guo 2025-03-21 15:09:26 Re: BUG #18859: ERROR: unexpected plan node type: 356