Re: CustomScan support on readfuncs.c - Mailing list pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, September 29, 2015 12:08 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: Re: [HACKERS] CustomScan support on readfuncs.c
> 
> 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?
>
I have no preference here.

Even if we dump library_name/symbol_name as if field in CustomScan,
not CustomScanMethods, in a similar way, we cannot use WRITE_STRING_FIELD
here, because its 'fldname' assumes these members are direct field of
CustomScan.
 /* Write a character-string (possibly NULL) field */ #define WRITE_STRING_FIELD(fldname) \     (appendStringInfo(str,
":" CppAsString(fldname) " "), \      _outToken(str, node->fldname))
 



One other question I have. Do we have a portable way to lookup
a pair of library and symbol by address?
Glibc has dladdr() functions that returns these information,
however, manpage warned it is not defined by POSIX.
If we would be able to have any portable way, it may make the
interface simpler.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>