Re: CustomScan support on readfuncs.c

> On Sat, Nov 7, 2015 at 6:38 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>