> On Thu, Nov 19, 2015 at 10:11 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > > The above two points are for the case if and when extension want to use > > variable length fields for its private fields. > > So, nodeAlloc() callback is not a perfect answer for the use case because > > length of the variable length fields shall be (usually) determined by the > > value of another fields (like num_inner_rels, num_gpu_devices, ...) thus > > we cannot determine the correct length before read. > > > > Let's assume an custom-scan extension that wants to have: > > > > typedef struct { > > CustomScan cscan; > > int priv_value_1; > > long priv_value_2; > > extra_info_t extra_subplan_info[FLEXIBLE_ARRAY_MEMBER]; > > /* its length equal to number of sub-plans */ > > } ExampleScan; > > > > The "extnodename" within CustomScan allows to pull callback functions > > to handle read node from the serialized format. > > However, nodeAlloc() callback cannot determine the correct length > > (= number of sub-plans in this example) prior to read 'cscan' part. > > > > So, I'd like to suggest _readCustomScan (and other extendable nodes > > also) read tokens on local CustomScan variable once, then call > > Node *(nodeRead)(Node *local_node) > > to allocate entire ExampleScan node and read other private fields. > > > > The local_node is already filled up by the core backend prior to > > the callback invocation, so extension can know how many sub-plans > > are expected thus how many private tokens shall appear. > > It also means extension can know exact length of the ExampleScan > > node, so it can allocate the node as expected then fill up > > remaining private tokens. > > On second thought, I think we should insist that nodes have to be > fixed-size. This sounds like a mess. If the node needs a variable > amount of storage for something, it can store a pointer to a > separately-allocated array someplace inside of it. That's what > existing nodes do, and it works fine. > OK, let's have "node_size" instead of nodeAlloc callback and other stuffs.
Please wait for a patch. -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers