Re: delayed initialization in worktable scan

Andres Freund <andres(at)anarazel(dot)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