On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch either. Much of the new code is called immediately adjacent to an FDW callback which could pretty trivially do the same thing itself, if needed.
Another idea about that code is to call that code in eg, ExecProcNode, instead of calling ExecForeignScan there. I think that that might be much cleaner and resolve the naming problem below.
And much of it is contingent on whether estate->es_epqTuple != NULL and scanrelid == 0, but perhaps out would be better to check whether the subplan is actually present instead of checking whether we think it should be present.
Agreed with this.
Also, the naming is a bit weird: node->fs_subplan gets shoved into outerPlanState(), which seems like a kludge.
And with this. Proposals welcome.
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.
Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
