On Tue, Jan 6, 2015 at 9:17 AM, Kouhei Kaigai <kaigai@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