> On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > Sorry for my late response. I've been unavailable to have enough
> > time to touch code for the last 1.5 month.
> >
> > The attached patch is a revised one to handle private data of
> > foregn/custom scan node more gracefully.
> >
> > The overall consensus upthread were:
> > - A new ExtensibleNodeMethods structure defines a unique name
> > and a set of callbacks to handle node copy, serialization,
> > deserialization and equality checks.
> > - (Foreign|Custom)(Path|Scan|ScanState) are first host of the
> > ExtensibleNodeMethods, to allow extension to define larger
> > structure to store its private fields.
> > - ExtensibleNodeMethods does not support variable length
> > structure (like a structure with an array on the tail, use
> > separately allocated array).
> > - ExtensibleNodeMethods shall be registered on _PG_init() of
> > extensions.
> >
> > The 'pgsql-v9.6-custom-private.v3.patch' is the main part of
> > this feature. As I pointed out before, it uses dynhash instead
> > of the self invented hash table.
>
> On a first read-through, I see nothing in this patch to which I would
> want to object except for the fact that the comments and documentation
> need some work from a native speaker of English. It looks like what
> we discussed, and I think it's an improvement over what we have now.
>
Thanks,
Do you think we shall allow to register same extensible node name for
different node types? Like, "GpuJoin" for any of CustomPath, CustomScan
and CustomScanState. Or, do we avoid this using different name for each?
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>