mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-06 15:24:56 +08:00
doc: In FDW handler docs, mark up scan_clauses with <literal>.
Etsuro Fujita
This commit is contained in:
parent
377790fbd7
commit
c70cc9afb3
@ -873,11 +873,11 @@ GetForeignServerByName(const char *name, bool missing_ok);
|
||||
|
||||
<para>
|
||||
In <function>GetForeignPlan</>, generally the passed-in target list can
|
||||
be copied into the plan node as-is. The passed scan_clauses list
|
||||
be copied into the plan node as-is. The passed <literal>scan_clauses</> list
|
||||
contains the same clauses as <literal>baserel->baserestrictinfo</>,
|
||||
but may be re-ordered for better execution efficiency. In simple cases
|
||||
the FDW can just strip <structname>RestrictInfo</> nodes from the
|
||||
scan_clauses list (using <function>extract_actual_clauses</>) and put
|
||||
<literal>scan_clauses</> list (using <function>extract_actual_clauses</>) and put
|
||||
all the clauses into the plan node's qual list, which means that all the
|
||||
clauses will be checked by the executor at run time. More complex FDWs
|
||||
may be able to check some of the clauses internally, in which case those
|
||||
@ -895,7 +895,7 @@ GetForeignServerByName(const char *name, bool missing_ok);
|
||||
affect the cost estimate for the path. The path's
|
||||
<structfield>fdw_private</> field would probably include a pointer to
|
||||
the identified clause's <structname>RestrictInfo</> node. Then
|
||||
<function>GetForeignPlan</> would remove that clause from scan_clauses,
|
||||
<function>GetForeignPlan</> would remove that clause from <literal>scan_clauses</>,
|
||||
but add the <replaceable>sub_expression</> to <structfield>fdw_exprs</>
|
||||
to ensure that it gets massaged into executable form. It would probably
|
||||
also put control information into the plan node's
|
||||
|
Loading…
Reference in New Issue
Block a user