On Mon, Dec 7, 2015 at 12:25 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
>> 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:
http://www.postgresql.org/message-id/CA+TgmoZ5G+ZGPh3STMGM6cWgTOywz3N1PjSw6Lvhz31ofgLZVw@mail.gmail.com
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company