From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Geier <david@swarm64.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: search_plan_tree(): handling of non-leaf CustomScanState nodes
 causes segfault
In-reply-to: <3ad851cf-ce22-ace0-726d-56209e214981@swarm64.com>
References: <0253344d-9bdd-11c4-7f0d-d88c02cd7991@swarm64.com>
 <347100.1610995608@sss.pgh.pa.us>
 <3ad851cf-ce22-ace0-726d-56209e214981@swarm64.com>
Comments: In-reply-to David Geier <david@swarm64.com>
	message dated "Mon, 18 Jan 2021 22:32:12 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <416506.1611009730.1@sss.pgh.pa.us>
Date: Mon, 18 Jan 2021 17:42:10 -0500
Message-ID: <416507.1611009730@sss.pgh.pa.us>
Precedence: bulk

David Geier <david@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