Re: CustomScan support on readfuncs.c

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