> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > > Are you suggesting to pass the object name on software build time? > > Yes. That's what test_shm_mq and worker_spi already do: > > sprintf(worker.bgw_library_name, "test_shm_mq"); > OK, I ripped out the portion around dfmgr.c.
> > If so, it may load incorrect libraries when DBA renamed its filename. > > At least, PostgreSQL cannot prevent DBA to rename library filenames > > even if they try to deploy "pg_strom.so", "pg_strom.20151106.so" and > > "pg_strom.20151030_bug.so" on same directory. > > I agree. But that's not a new problem that needs to be solved by this > patch. It already exists - see above. > It still may be a potential problem, even though a corner case. I'll try to implement an internal API to know "what is my name". The attached main patch (custom-scan-on-readfuncs.v3.patch) once removes TextOutCustomScan, thus all the serialized tokens become known to the core backend, and add _readCustomScan() at readfuncs.c. It deserializes CustomScan nodes from cstring tokens, especially, reloads the pointer of CustomScanMethods tables using a pair of library name and symbol name. Thus, it also requires custom scan providers to keep the methods table visible from external objects. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com>
custom-scan-on-readfuncs.v3.patch
Description: custom-scan-on-readfuncs.v3.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
