On Mon, Mar 28, 2016 at 11:00 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: >> -----Original Message----- >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> Sent: Tuesday, March 29, 2016 10:54 AM >> To: Kaigai Kouhei(海外 浩平) >> Cc: Petr Jelinek; pgsql-hackers@postgresql.org >> Subject: Re: [HACKERS] Reworks of CustomScan serialization/deserialization >> >> On Mon, Mar 28, 2016 at 9:36 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: >> > I don't have a strong reason to keep these stuff in separate files. >> > Both stuffs covers similar features and amount of code are enough small. >> > So, the attached v4 just merged custom-node.[ch] stuff into extensible. >> > >> > Once we put similar routines closely, it may be better to consolidate >> > these routines. >> > As long as EXTNODENAME_MAX_LEN == CUSTOM_NAME_MAX_LEN, both features >> > have identical structure layout, so it is easy to call an internal >> > common function to register or find out a table of callbacks according >> > to the function actually called by other modules. >> > >> > I'm inclined to think to replace EXTNODENAME_MAX_LEN and >> > CUSTOM_NAME_MAX_LEN by NAMEDATALEN again, to fit structure layout. >> >> I don't think that we need both EXTNODENAME_MAX_LEN and >> CUSTOM_NAME_MAX_LEN; we can use EXTNODENAME_MAX_LEN for both. I'm >> opposed to using NAMEDATALEN for anything unrelated to the size of a >> Name. If it's not being stored in a catalog, it doesn't need to care. >> > OK, I adjusted the v4 patch to use EXTNODENAME_MAX_LEN for both. > > The structure of hash entry was revised as follows, then registered via > an internal common function: RegisterExtensibleNodeEntry, and found out > via also an internal common function: GetExtensibleNodeEntry. > > typedef struct > { > char extnodename[EXTNODENAME_MAX_LEN]; > const void *extnodemethods; > } ExtensibleNodeEntry; > > ExtensibleNodeMethods and CustomScanMethods shall be stored in > 'extensible_node_methods' and 'custom_scan_methods' separatedly. > The entrypoint functions calls above internal common functions with > appropriate HTAB variable. > > It will be re-usable if we would have further extensible nodes in the > future versions.
Committed with a bit of wordsmithing. -- 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
