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. -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
