Andres Freund <and...@anarazel.de> writes: > Basically the issue is that in queries with two CTEs we can, at least > currently, end up with a WorkTable scans on a CTE we've not yet initialized, > due to the WorkTable scan of one CTE appearing in the other. Thus > ExecInitRecursiveUnion() hasn't yet set up the param we use in > nodeWorktablescan.c to find the tuplestore and the type of the tuples it > contains.
> I don't think this is a huge issue, but it surprised multiple times, so I'd > like to expand the comment. At least for me it's hard to get from "corner > cases" to one worktable scan appearing in another CTE and to mutally recursive > CTEs. Sure. I think I wrote the comment the way I did because I hadn't done enough analysis to be sure that mutually recursive CTEs was the only way to trigger it. But as long as you say "for example" or words to that effect, I don't have a problem with giving an example case here. > I did go down the rabbit hole of trying to avoid this issue because it "feels > wrong" to not know the return type of an executor node during initialization. > ... > I'm not sure it's worth changing this. Or whether that'd be the right > approach. I wouldn't bother unless we find a compelling reason to need the info earlier. regards, tom lane