On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > Then, let's look back a bit. Next issue is how to reproduce > the "methods" pointer from the text representation. > I try to lookup the methods table using a pair of library > and symbol name; probably, it is a straightforward way. > The "methods" field is put earlier than all private fields > generated by TextOutCustomScan, so it should be reconstructable > prior to TextReadCustomScan. > To support this feature, I had to add an interface contract > that requires extensions to put library and symbol name on > CustomScanMethods table. > Although INIT_CUSTOM_SCAN_METHODS() macro can set up these > fields, author of extension needs to pay attention. > > In addition to these enhancement, a new NodeCopyCustomScan > callback eliminates a restriction; custom-scan provider > cannot define its own structure that embeds CustomScan. > Only CSP knows exact size of the structure, this callback > is intended to allocate a new one and copy the private fields, > but no need to copy the common fields. > > These three callbacks (one existing, two new) will make > CustomScan node copyObject, nodeToString and stringToNode > aware.
Instead of doing this: + /* Dump library and symbol name instead of raw pointer */ appendStringInfoString(str, " :methods "); - _outToken(str, node->methods->CustomName); + _outToken(str, node->methods->methods_library_name); + appendStringInfoChar(str, ' '); + _outToken(str, node->methods->methods_symbol_name); Suppose we just make library_name and symbol_name fields in the node itself, that are dumped and loaded like any others. Would that be better? -- 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