Re: CustomScan support on readfuncs.c
От | Kouhei Kaigai |
---|---|
Тема | Re: CustomScan support on readfuncs.c |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F80116F2F0@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | CustomScan support on readfuncs.c (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Список | 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 по дате отправления: