On Mon, Dec 7, 2015 at 12:25 AM, Etsuro Fujita
>> Instead, I think we should go the opposite direction and pass the
>> outerplan to GetForeignPlan after all. I was lulled into a full sense
>> of security by the realization that every FDW that uses this feature
>> MUST want to do outerPlan(scan_plan) = fdw_outerplan. That's true,
>> but irrelevant. The point is that the FDW might want to do something
>> additional, like frob the outer plan's tlist, and it can't do that if
>> we don't pass it fdw_outerplan. So we should do that, after all.
> As I proposed upthread, another idea would be to 1) to store an
> fdw_outerpath in the fdw_private list of a ForeignPath node, and then 2) to
> create an fdw_outerplan from *the fdw_outerpath stored into
> the fdw_private* in GetForeignPlan. One good thing for this is that we keep
> the API of create_foreignscan_path as-is. What do you think about that?
I don't think it's a good idea, per what I said in the first paragraph
of this email:
I think the core system likely needs visibility into where paths and
plans are present in node trees, and putting them somewhere inside
fdw_private would be going in the opposite direction.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: