On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: >> I'm wondering if there's another approach. If I understand correctly, >> there are two reasons why the current situation is untenable. The >> first is that ForeignRecheck always returns true, but we could instead >> call an FDW-supplied callback routine there. The callback could be >> optional, so that we just return true if there is none, which is nice >> for already-existing FDWs that then don't need to do anything. > > My question about this is, is the callback really needed? If there are any > FDWs that want to do the work *in their own way*, instead of just doing > ExecProcNode for executing a local join execution plan in case of foreign > join (or just doing ExecQual for checking remote quals in case of foreign > table), I'd agree with introducing the callback, but if not, I don't think > that that makes much sense.
It doesn't seem to me that it hurts much of anything to add the callback there, and it does provide some flexibility. Actually, I'm not really sure why we're thinking we need a subplan here at all, rather than just having a ForeignRecheck callback that can do whatever it needs to do with no particular help from the core infrastructure. I think you wrote some code to show how postgres_fdw would use the API you are proposing, but I can't find it. Can you point me in the right 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
