On Tue, Sep 29, 2015 at 6:19 PM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
>> On Mon, Sep 28, 2015 at 8:31 PM, Kouhei Kaigai <kai...@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.
> Let me confirm. Are you suggesting to have library_name/symbol_name
> in CustomScan, not CustomScanMethods?
> I prefer these fields are in CustomScanMethods because we don't need
> to setup them again once PG_init set up these symbols. CustomScan has
> to be created every time when it is chosen by planner.
True. But that doesn't cost much. I'm not sure it's better, so if
you don't like it, don't worry about it.
>> > 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.
> It looks up an address by a pair of library and symbol name....
> What I'm looking for is a portable function that looks up a pair
> of library and symbol name by an address, like dladdr() of glibc.
> I don't know whether other *nix or windows have these infrastructure.
No, that doesn't exist, and the chances of us trying add that
infrastructure for this feature are nil.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: