Re: CustomScan support on readfuncs.c - Mailing list pgsql-hackers

From Kouhei Kaigai
Subject Re: CustomScan support on readfuncs.c
Date
Msg-id 9A28C8860F777E439AA12E8AEA7694F80116F2F0@BPXM15GP.gisp.nec.co.jp
Whole thread Raw
In response to CustomScan support on readfuncs.c  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
> On Thu, Nov 12, 2015 at 7:59 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >> On Mon, Nov 9, 2015 at 9:46 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
> >> > 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.
> >>
> >> Committed with some kibitzing.
> >>
> > Thanks,
> >
> > How do we deal with TextOutCustomScan in the v9.5 tree?
> > I think we ought to remove this callback also prior to v9.5 release.
> 
> I'll do that if there's a clear consensus in favor.  I wasn't sure it
> really made sense so close to release.
>
Unless we don't reach a consensus in the "CustomScan in a larger
structure" thread, TextOutCustomScan callback becomes obsoleted in
the v9.6 release.

So, I think this callback shall be dropped once.
Let's wait for a few days for other persons' opinion?

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Documentation tweak for row-valued expressions and null
Next
From: Robert Haas
Date:
Subject: Re: Dangling Client Backend Process