> On Fri, Sep 25, 2015 at 6:49 AM, Kouhei Kaigai <kai...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
