On Wed, Dec 18, 2024 at 7:05 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > David Rowley <dgrowle...@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
