From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CustomScan support on readfuncs.c |
Date: | 2015-09-28 15:08:09 |
Message-ID: | CA+TgmoaCZ3CkmqtJhZLCfVtC4zycePxMHQUu1cZVwztvaN3riQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 24, 2015 at 9:19 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-09-28 15:10:52 | Re: 9.3.9 and pg_multixact corruption |
Previous Message | Robert Haas | 2015-09-28 15:03:18 | Re: [PROPOSAL] VACUUM Progress Checker. |