On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
>> 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))
Well that's exactly what I was suggesting: making them a direct field
of CustomScan.
> 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.
Yes: load_external_function.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
