Re: Custom Scan APIs (Re: Custom Plan node)

> I was thinking more like
>
> typedef struct CustomPathFuncs {
> const char *name; /* used for debugging purposes only */
> NodeCopy_function node_copy;
> NodeTextOut_function node_textout;
> ... etc etc etc ...
> } CustomPathFuncs;
>
> typedef struct CustomPath {
> Path path;
> const CustomPathFuncs *funcs;
> ... maybe a few more fields here, but not too darn many ...
> } CustomPath;
>
> and similarly for CustomPlan.
>
> The advantage of this way is it's very cheap for (what I expect will be)
> the common case where an extension has a fixed set of support functions
> for its custom paths and plans. It just declares a static constant
> CustomPathFuncs struct, and puts a pointer to that into its paths.
>
> If an extension really needs to set the support functions on a per-object
> basis, it can do this:
>
> typdef struct MyCustomPath {
> CustomPath cpath;
> CustomPathFuncs funcs;
> ... more fields ...
> } MyCustomPath;
>
> and then initialization of a MyCustomPath would include
>
> mypath->cpath.funcs = &mypath->funcs;
> mypath->funcs.node_copy = MyCustomPathCopy;
> ... etc etc ...
>
> In this case we're arguably wasting one pointer worth of space in the path,
> but considering the number of function pointers such a path will be carrying,
> I don't think that's much of an objection.
>
That is exactly same as my expectation, and no objection here.
Thanks for your clarification.

> >> So? If you did that, then you wouldn't have renumbered the Vars as
> >> INNER/OUTER. I don't believe that CUSTOM_VAR is necessary at all; if
> >> it is needed, then there would also be a need for an additional tuple
> >> slot in executor contexts, which you haven't provided.
>
> > For example, the enhanced postgres_fdw fetches the result set of
> > remote join query, thus a tuple contains the fields come from both side.
> > In this case, what varno shall be suitable to put?
>
> Not sure what we'd do for the general case, but CUSTOM_VAR isn't the solution.
> Consider for example a join where both tables supply columns named "id"
> --- if you put them both in one tupledesc then there's no non-kluge way
> to identify them.
>
> Possibly the route to a solution involves adding another plan-node callback
> function that ruleutils.c would use for printing Vars in custom join nodes.
> Or maybe we could let the Vars keep their original RTE numbers, though that
> would complicate life at execution time.
>
My preference is earlier one, because complication in execution time may
make performance degradation.
Once two tuples get joined in custom-node, only extension can know which
relation is the origin of a particular attribute in the unified tuple.
So, it seems to me reasonable extension has to provide a hint to resolve
the Var naming.
Probably, another callback that provides a translation table from a Var
node that reference custom-plan but originated from either of subtree.
(It looks like a translated_vars in prepunion.c)

For example, let's assume here is a Var node with INDEX_VAR in the tlist
of custom-plan. It eventually references ecxt_scantuple in the execution
time, and this tuple-slot will keep a joined tuple being originated from
two relations. If its varattno=9 came from the column varno=1/varatno=3,
we like to print its original name. If we can have a translation table
like translated_vars, it allows to translate an attribute number on the
custom-plan into its original ones.
Even it might be abuse of INDEX_VAR, it seems to me a good idea.
Also, I don't like to re-define the meaning of INNER_VAR/OUTER_VAR
because custom-plan may have both of left-/right-subtree, thus it makes
sense to support a case when both of tupleslots are available.

> Anyway, if we're going to punt on add_join_path_hook for the time being,
> this problem can probably be left to solve later. It won't arise for simple
> table-scan cases, nor for single-input plan nodes such as sorts.
>
Yes, it is a problem if number of input plans is larger then 1.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>