> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> Sent: Saturday, November 07, 2015 1:42 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila; Andres Freund; pgsql-hackers
> Subject: Re: [HACKERS] CustomScan support on readfuncs.c
>
> On Fri, Nov 6, 2015 at 2:02 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> > I tried to split the previous version into two portions.
> >
> > - custom-scan-on-readfuncs.v2.patch
> > It allows to serialize/deserialize CustomScan node as discussed upthread.
> > Regarding of get_current_library_filename(), I keep this feature as
> > the previous version right now, because I have no good alternatives.
>
> Why can't the library just pass its name as a constant string?
>
Are you suggesting to pass the object name on software build time?
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 don't know portable way to get library name on run-time, so, all we
can use are environment specific.- dladdr(3) : specific to glibc- /proc/<PID>/maps : specific to Linux
Thus, I thought the backend assist is the most reasonable way here.
> > In this patch, the role of TextReadCustomScan callback is to clean out
> > any tokens generated by TextOutCustomScan. The CustomScan node itself
> > can be reconstructed with common portion because we expect custom_exprs
> > and custom_private have objects which are safe to copyObject().
>
> Some of the documentation changes for the embed-the-struct changes are
> still present in the readfuncs patch.
>
> Rather than adding TextReadCustomScan, I think we should rip
> TextOutputCustomScan out. It seems like a useless appendage.
>
OK, I'll once remove TextOut, then add it later.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>