Re: CustomScan support on readfuncs.c

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(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:02:06
Message-ID: CAA4eK1L+UpNA6wDHbcADuFHCagJWaSUVqXEcVTVveV57954cTQ@mail.gmail.com
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().

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-09-25 07:25:17 Re: CustomScan support on readfuncs.c
Previous Message Michael Paquier 2015-09-25 06:29:43 Re: In-core regression tests for replication, cascading, archiving, PITR, etc.