On Wed, Dec 18, 2024 at 7:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
> > The slightly annoying thing here is that the attached patch passes the
> > TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> > Append does not go to much effort to setting a fixed
> > TupleTableSlotOps. Really it could loop over all the child plans and
> > check if those have fixed slot types of the same type and then fix its
> > own resulting slot. For nodeSetOps.c use case, since the planner
> > (currently) injects the flag into the target list, it'll always
> > project and use a virtual slot type. It's maybe worth coming back and
> > adjusting nodeAppend.c so it works a bit harder to fix its slot type.
> > I think that's likely for another patch, however. Tom is also
> > currently working on nodeSetOps.c to change how all this works so it
> > no longer uses the flags method to determine the outer and inner
> > sides.
>
> Yeah, I see no point in putting effort into improving the current
> nodeSetOp implementation. There might be a reason to change
> nodeAppend as you suggest for other use-cases though.
Should we be concerned about passing a NULL TupleTableSlotOps in
nodeRecursiveUnion.c? The query below triggers the same assert
failure: the slot is expected to be TTSOpsMinimalTuple, but it is
TTSOpsBufferHeapTuple.
create table t (a int);
insert into t values (1), (1);
with recursive cte (a) as (select a from t union select a from cte)
select a from cte;
Thanks
Richard
