rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: In FDW handler docs, mark up scan_clauses with <literal>. 

Etsuro Fujita
This commit is contained in:
Robert Haas 2014-05-05 10:04:02 -04:00
parent 377790fbd7
commit c70cc9afb3
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/fdwhandler.sgml
View File

@ -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-&gt;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