David Geier <da...@swarm64.com> writes: > On 18.01.21 19:46, Tom Lane wrote: >> Hm. I agree that we shouldn't simply assume that ss_currentRelation >> isn't null. However, we cannot make search_plan_tree() descend >> through non-leaf CustomScan nodes, because we don't know what processing >> is involved there. We need to find a scan that is guaranteed to return >> rows that are one-to-one with the cursor output. This is why the function >> doesn't descend through join or aggregation nodes, and I see no argument >> by which we should assume we know more about what a customscan node will >> do than we know about those.
> That makes sense. Thanks for the explanation. OK, cool. I was afraid you'd argue that you really needed your CustomScan node to be transparent in such cases. We could imagine inventing an additional custom-scan-provider callback to embed the necessary knowledge, but I'd rather not add the complexity until someone has a use-case. > I updated the patch to match your proposal. WFM, will push in a bit. regards, tom lane