On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai <kaigai@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