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:

Reply via email to