On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > I guess we will put a pointer to static ExtensibleNodeMethods structure > on ForeignScan, CustomScan, CustomScanState and etc...
I think that makes it confusing. What I'd prefer to do is have only the name stored in the node, and then people who need methods can look up those methods based on the name. > Let me write down the steps for deserialization. Please correct me if it is > not what you are thinking. > First, stringToNode picks up a token that shall have node label, like > "SEQSCAN", "CUSTOMSCAN" and others. Once we can identify the following > tokens belong to CustomScan node, it can make advance the pg_strtok pointer > until "methods" field. The method field is consists of a pair of library_name > and symbol_name, then it tries to load the library and resolve the symbol. No. It reads the "extnodename" field (or whatever we decide to call it) and calls GetExtensibleNodeMethods() on that name. That name returns the appropriate structure. C libraries that get loaded into the server can register their extensible node types at _PG_init() time. > Even if library was not loaded on the worker side, this step allows to ensure > the library gets loaded, thus, PG_init() can RegisterExtensibleNodeMethods. A parallel worker will load the same loadable modules which the master has got loaded. If you use some other kind of background worker, of course, you're on your own. > I have two concerns on the above proposition. > 1) 'node_size' field implies user defined structure to have fixed length. > Extension may want to use variable length structure. The example below > shows GpuJoinState has multiple innerState structure according to the > number of inner relations joined at once. > https://github.com/pg-strom/devel/blob/master/src/gpujoin.c#L240 OK, we can replace the node_size field with an allocator callback: Node (*nodeAlloc)(void) or something like that. > 2) It may be valuable if 'nodeRead(void)' can take an argument of the > knows/common portion of ForeignScan and etc... It allows extension > to adjust number of private fields according to the known part. > For example, I can expect flexible length private fields according > to the length of custom_subplans list. I don't understand this bit. -- 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
