<structname>Plan</structname> nodes.
    <structfield>custom_exprs</structfield> should be used to
    store expression trees that will need to be fixed up by
    <filename>setrefs.c</filename> and <filename>subselect.c</filename>, while
    <structfield>custom_private</structfield> should be used to store other private data
    that is only used by the custom scan provider itself.
    <structfield>custom_scan_tlist</structfield> can be NIL when scanning a base
    relation, indicating that the custom scan returns scan tuples that match
    the base relation's row type.  Otherwise it is a target list describing
    the actual scan tuples.  <structfield>custom_scan_tlist</structfield> must be
    provided for joins, and could be provided for scans if the custom scan
    provider can compute some non-Var expressions.
    <structfield>custom_relids</structfield> is set by the core code to the set of
    relations (range table indexes) that this scan node handles; except when
    this scan is replacing a join, it will have only one member.
    <structfield>methods</structfield> must point to a (usually statically allocated)
    object implementing the required custom scan methods, which are further
    detailed below.
  </para>

  <para>
   When a <structname>CustomScan</structname> scans a single relation,
   <structfield>scan.scanrelid</structfield> must be the range table index of the table
   to be scanned.  When it replaces a join, <structfield>scan.scanrelid</structfield>
   should be zero.
  </para>

  <para>
   Plan trees must be able to be duplicated using <function>copyObject</function>,
   so all the data stored within the <quote>custom</quote> fields must consist of
   nodes that that function can handle.  Furthermore, custom scan providers
   cannot substitute a larger structure that embeds
   a <structname>CustomScan</structname> for the structure itself, as would be possible
   for a <structname>CustomPath</structname> or <structname>CustomScanState</structname>.
  </para>

  <sect2 id="custom-scan-plan-callbacks">
   <title>Custom Scan Plan Callbacks</title>
   <para>
<programlisting>
Node *(*CreateCustomScanState) (CustomScan *cscan);
</programlisting>
    Allocate a <structname>CustomScanState</structname> for this
    <structname>CustomScan</structname>.  The actual allocation will often be larger than
    required for an ordinary <structname>CustomScanState</structname>, because many
    providers will wish to embed that as the first field of a larger structure.
    The value returned must have the node tag and <structfield>methods</structfield>
    set appropriately, but other fields should be left as zeroes at this
    stage; after <function>ExecInitCustomScan</function> performs basic initialization,
    the <function>BeginCustomScan</function> callback will be invoked to give the
    custom scan provider a chance to do whatever else is needed.
   </para>
  </sect2>
 </sect1>

 <sect1 id="custom-scan-execution">
  <title>Executing Custom Scans</title>

  <para>
   When a <structfield>CustomScan</structfield> is executed, its execution state is
   represented by a <structfield>CustomScanState</structfield>, which is declared as
   follows:
<programlisting>
typedef struct CustomScanState
{
    ScanState ss;
    uint32    flags;
    const CustomExecMethods *methods;
} CustomScanState;
</programlisting>
  </para>

  <para>
   <structfield>ss</structfield> is initialized as for any other scan state,
   except that if the scan is for a join rather than a base relation,
   <literal>ss.ss_currentRelation</literal> is left NULL.
   <structfield>flags</structfield> is a bit mask with the same meaning as in
   <structname>CustomPath</structname> and <structname>CustomScan</structname>.
   <structfield>methods</structfield> must point to a (usually statically allocated)
   object implementing the required custom scan state methods, which are
   further detailed below.  Typically, a <structname>CustomScanState</structname>,