> On Fri, Sep 25, 2015 at 6:49 AM, Kouhei Kaigai <kaigai@ak.jp.nec.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@ak.jp.nec.com>
