Re: CustomScan support on readfuncs.c

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CustomScan support on readfuncs.c
Date: 2015-09-25 07:25:17
Message-ID: 9A28C8860F777E439AA12E8AEA7694F80114AB7F@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Fri, Sep 25, 2015 at 6:49 AM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>
>
> Hi,
>
> I tried to define two additional callbacks to support CustomScan
> on readfuncs.c.
>
> First of all, we need to pay attention how to treat output of
> TextOutCustomScan when additional text output is generated.
> Only custom-scan provider knows what shall be displayed, so
> all we can do is invoke a new callback: TextReadCustomScan().
> Because private fields shall be displayed next to the common
> field of CustomScan, this callback is invoked once pg_strtok
> pointer reached to the last field of CustomScan. Then, custom
> scan provider allocates CustomScan or a structure embedding
> CustomScan; only CSP knows exact size to be allocated.
> It can fetch some tokens using pg_strtok and reconstruct its
> private fields, but no need to restore the common field because
> it shall be done by _readCustomScan.
>
>
>
> So will the specification of TextReadCustomScan() and
> TextOutCustomScan() ensures that they don't access the common
> fields (like custom_private or others) of CustomScan?
> If they change/overwrite them in some way, then I think _readCustomScan()
> won't work because it doesn't take into account that common fields could
> have been updated by TextReadCustomScan().
>
Yes. Even if callback of TextReadCustomScan() wants to change or
overwrite, then it is eventually overwritten by the core.
If we allow custom-scan provide to adjust common fields of CustomScan,
it is a change of interface role because the relevant callbacks (TextOut,
TextRead and NodeCopy) are expected to perform faithfully according to
the supplied node.
If extension really wants to adjust plan-node, probably, something like
plan_tree_mutator() should be the place to do.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Seltenreich 2015-09-25 07:37:39 Re: 9.3.9 and pg_multixact corruption
Previous Message Amit Kapila 2015-09-25 07:02:06 Re: CustomScan support on readfuncs.c