Hello, At Thu, 10 Sep 2015 17:24:00 -0400, Robert Haas <robertmh...@gmail.com> wrote in <CA+TgmobxksR2=3wEdY5cEgpd1hQ6Z0WoZEBBoxgs=xkzpbf...@mail.gmail.com> > 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?
I've heard that the reason for the (fs_)subplan is that it should be initialized using create_plan_recurse, set_plan_refs and finalyze_plan (or others), which are static functions in the planner, unavailable in fdw code. Is this pointless? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
