On Tue, Jan 6, 2015 at 9:17 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > The attached patch is newer revision of custom-/foreign-join > interface.
It seems that the basic purpose of this patch is to allow a foreign scan or custom scan to have scanrelid == 0, reflecting the case where we are scanning a joinrel rather than a baserel. The major problem that seems to create is that we can't set the target list from the relation descriptor, because there isn't one. To work around that, you've added fdw_ps_list and custom_ps_tlist, which the FDW or custom-plan provider must set. I don't know off-hand whether that's a good interface or not. How does the FDW know what to stick in there? There's a comment that seems to be trying to explain this: + * An optional fdw_ps_tlist is used to map a reference to an attribute of + * underlying relation(s) on a pair of INDEX_VAR and alternative varattno. + * It looks like a scan on pseudo relation that is usually result of + * relations join on remote data source, and FDW driver is responsible to + * set expected target list for this. If FDW returns records as foreign- + * table definition, just put NIL here. ...but I can't understand what that's telling me. You've added an "Oid fdw_handler" field to the ForeignScan and RelOptInfo structures. I think this is the OID of the pg_proc entry for the handler function; and I think we need it because, if scanrelid == 0 then we don't have a relation that we can trace to a foreign table, to a server, to an FDW, and then to a handler. So we need to get that information some other way. When building joinrels, the fdw_handler OID, and the associated routine, are propagated from any two relations that share the same fdw_handler OID to the resulting joinrel. I guess that's reasonable, although it feels a little weird that we're copying around both the OID and the structure-pointer. For non-obvious reasons, you've made create_plan_recurse() non-static. -- 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