> -----Original Message----- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Monday, February 08, 2016 11:59 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Andres Freund; Amit Kapila; pgsql-hackers > Subject: ##freemail## Re: CustomScan in a larger structure (RE: [HACKERS] > CustomScan support on readfuncs.c) > > On Sun, Feb 7, 2016 at 7:28 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > > The new callbacks of T_ExtensibleNode will replace the necessity to > > form and deform process of private values, like as: > > https://github.com/pg-strom/devel/blob/master/src/gpujoin.c#L114 > > Yeah. > > > It transforms a bunch of internal data of CustomScan (similar to the > > extended fields in T_ExtensibleNode) to/from the node functions > > understandable forms for copy, input and output support. > > I think it implies you proposition is workable. > > > > I'd like to follow this proposition basically. > > On the other hands, I have two points I want to pay attention. > > > > 1. At this moment, it is allowed to define a larger structure that > > embeds CustomPath and CustomScanState by extension. How do we treat > > this coding manner in this case? Especially, CustomScanState has no > > private pointer dereference because it assumes an extension define > > a larger structure. Of course, we don't need to care about node > > operations on Path and PlanState nodes, but right now. > > I see no real advantage in letting a CustomPath be larger. If > custom_private can include extension-defined node types, that seems > good enough. On the other hand, if CustomScanState can be larger, > that seems fine. We don't really need any special support for that, > do we? > Yes. Right now, we have no code path that handles PlanState or its inheritance using node operations. So, it is not a real problem.
> > 2. I intended to replace LibraryName and SymbolName fields from the > > CustomScanMethods structure by integration of extensible node type. > > We had to give a pair of these identifiers because custom scan provider > > has no registration points at this moment. A little concern is extension > > has to assume a particular filename of itself. > > But, probably, it shall be a separated discussion. My preference is > > preliminary registration of custom scan provider by its name, as well > > as extensible node. > > Seems like we could just leave the CustomScan stuff alone and worry > about this as a separate facility. > OK > > Towards the last question; whether *_private shall be void * or List *, > > I want to keep fdw_private and custom_private as List * pointer, because > > a new node type definition is a bit overdone job if this FDW or CSP will > > take only a few private fields with primitive data types. > > It is a preferable features when extension defines ten or more private > > fields. > > Well, I suggested Node *, not void *. A Node can be a List, but not > every Node is a List. > It is pretty good! The attached patch (primary one) implements the above idea. Now ExtensibleNode works as a basis structure of data container, regardless of CustomScan and ForeignScan. Also, fdw_private and custom_private are de-defined to Node * type from List * type. It affected to a few FDW APIs. The secondary patch is a demonstration of new ExtensibleNode using postgres_fdw extension. Its private data are expected to be packed in a list with a particular order. Self defined structure allows to keep these variables without ugly pack/unpacking. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com>
pgsql-v9.6-custom-private.v5.demo.patch
Description: pgsql-v9.6-custom-private.v5.demo.patch
pgsql-v9.6-custom-private.v5.patch
Description: pgsql-v9.6-custom-private.v5.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
