On Mon, Dec 7, 2015 at 12:25 AM, Etsuro Fujita <fujita.ets...@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+zgph3stmgm6cwgtoywz3n1pjsw6lvhz31ofgl...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
