On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > To test this change, I think we should update the postgres_fdw patch so as > to add the RecheckForeignScan. > > Having said that, as I said previously, I don't see much value in adding the > callback routine, to be honest. I know KaiGai-san considers that that would > be useful for custom joins, but I don't think that that would be useful even > for foreign joins, because I think that in case of foreign joins, the > practical implementation of that routine in FDWs would be to create a > secondary plan and execute that plan by performing ExecProcNode, as my patch > does [1]. Maybe I'm missing something, though.
I really don't see why you're fighting on this point. Making this a generic feature will require only a few extra lines of code for FDW authors. If this were going to cause some great inconvenience for FDW authors, then I'd agree it isn't worth it. But I see zero evidence that this is actually the case. From my point of view I'm now thinking this solution has two parts: (1) Let foreign scans have inner and outer subplans. For this purpose, we only need one, but it's no more work to enable both, so we may as well. If we had some reason, we could add a list of subplans of arbitrary length, but there doesn't seem to be an urgent need for that. (2) Add a recheck callback. If the foreign data wrapper wants to adopt the solution you're proposing, the recheck callback can call ExecProcNode(outerPlanState(node)). I don't think this should end up being more than a few lines of code, although of course we should verify that. So no problem: postgres_fdw and any other FDWs where the remote side is a database can easily delegate to a subplan, and anybody who wants to do something else still can. What is not to like about that? -- 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
