Update xfunc.sgml-200704

——row5，调英为：
  <title>User-Defined Functions</title>

——row134，调英为：
   <title>User-Defined Procedures</title>

——row1994至1997，调英为：
     nested-loop join, since <structname>g</structname> has no actual lateral dependency
     on <structname>tab</structname>.  That would result in a different output row
     order.  Set-returning functions in the select list are always evaluated
     as though they are on the inside of a nested-loop join with the rest of

——row3863，删英和翻为：
<!--==========================orignal english content==========================
        <row>
         <entry><type>abstime</type></entry>
         <entry><type>AbsoluteTime</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>
____________________________________________________________________________-->
        <row>
         <entry><type>abstime</type></entry>
         <entry><type>AbsoluteTime</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>
<!--==========================orignal english content==========================
        <row>
         <entry><type>bigint</type> (<type>int8</type>)</entry>
         <entry><type>int64</type></entry>
         <entry><filename>postgres.h</filename></entry>
        </row>
____________________________________________________________________________-->
        <row>
         <entry><type>bigint</type> (<type>int8</type>)</entry>
         <entry><type>int64</type></entry>
         <entry><filename>postgres.h</filename></entry>
        </row>

——row4103，删英和翻为：
<!--==========================orignal english content==========================
        <row>
         <entry><type>reltime</type></entry>
         <entry><type>RelativeTime</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>
____________________________________________________________________________-->
        <row>
         <entry><type>reltime</type></entry>
         <entry><type>RelativeTime</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>

——row4163，删英和翻为：
<!--==========================orignal english content==========================
        <row>
         <entry><type>tinterval</type></entry>
         <entry><type>TimeInterval</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>
____________________________________________________________________________-->
        <row>
         <entry><type>tinterval</type></entry>
         <entry><type>TimeInterval</type></entry>
         <entry><filename>utils/nabstime.h</filename></entry>
        </row>

——row4841，调英为：
    <title>Composite-Type Arguments</title>

——row5350，删英为：
    /*
     * OPTIONAL pointer to result slot
     *
     * This is obsolete and only present for backward compatibility, viz,
     * user-defined SRFs that use the deprecated TupleDescGetSlot().
     */
    TupleTableSlot *slot;
——row5419，删翻为：
    /*
     * 可选：指向结果槽的指针
     *
     * 这已经被废弃并且只为向后兼容而存在，也就是那些使用被废弃的
     * TupleDescGetSlot() 的用户定义 SRF。.
     */
    TupleTableSlot *slot;

——row6139，删英和翻为：
   <sect2 id="xfunc-transform-functions">
<!--==========================orignal english content==========================
    <title>Transform Functions</title>
____________________________________________________________________________-->
    <title>转换函数</title>

<!--==========================orignal english content==========================
    <para>
     Some function calls can be simplified during planning based on
     properties specific to the function.  For example,
     <literal>int4mul(n, 1)</literal> could be simplified to just <literal>n</literal>.
     To define such function-specific optimizations, write a
     <firstterm>transform function</firstterm> and place its OID in the
     <structfield>protransform</structfield> field of the primary function's
     <structname>pg_proc</structname> entry.  The transform function must have the SQL
     signature <literal>protransform(internal) RETURNS internal</literal>.  The
     argument, actually <type>FuncExpr *</type>, is a dummy node representing a
     call to the primary function.  If the transform function's study of the
     expression tree proves that a simplified expression tree can substitute
     for all possible concrete calls represented thereby, build and return
     that simplified expression.  Otherwise, return a <literal>NULL</literal>
     pointer (<emphasis>not</emphasis> a SQL null).
    </para>
____________________________________________________________________________-->
    <para>
     一些函数调用可以在规划期间基于该函数的特定的属性被简化。例如，
     <literal>int4mul(n, 1)</literal>可以被简化为<literal>n</literal>。要定义这种
     与函数相关的优化，可以写一个<firstterm>转换函数</firstterm>并且将其 OID
     放在主函数的<structname>pg_proc</structname>项的
     <structfield>protransform</structfield>域中。该转换函数必须具有 SQL 式样
     <literal>protransform(internal) RETURNS internal</literal>。其参数（实
     际是<type>FuncExpr *</type>）是一个表示对主函数调用的伪节点。如果
     该转换函数对表达式树的研究证明一个简化的表达式树能够替代所有可能
     的具体调用，则会构造并且返回简化的表达式。否则会返回一个
     <literal>NULL</literal>指针（<emphasis>不是</emphasis>一个 SQL 空值）。
    </para>

<!--==========================orignal english content==========================
    <para>
     We make no guarantee that <productname>PostgreSQL</productname> will never call the
     primary function in cases that the transform function could simplify.
     Ensure rigorous equivalence between the simplified expression and an
     actual call to the primary function.
    </para>
____________________________________________________________________________-->
    <para>
     我们不保证<productname>PostgreSQL</productname>在转换函数可以进行简化的
     情况下绝不会调用主函数。要保证简化后的表达式和对主函数的一次实际
     调用是严格等价的。
    </para>

<!--==========================orignal english content==========================
    <para>
     Currently, this facility is not exposed to users at the SQL level
     because of security concerns, so it is only practical to use for
     optimizing built-in functions.
    </para>
____________________________________________________________________________-->
    <para>
     当前，由于安全性的考虑，这种功能没有在 SQL 层面上显示给用户。因此，
     这种功能实际只用于优化内建函数。
    </para>
   </sect2>

——row6363至6562，增英和翻为：
  <sect1 id="xfunc-optimization">
<!--==========================orignal english content==========================
   <title>Function Optimization Information</title>
____________________________________________________________________________-->
   <title>函数优化信息</title>

<!--==========================orignal english content==========================
  <indexterm zone="xfunc-optimization">
   <primary>optimization information</primary>
   <secondary>for functions</secondary>
  </indexterm>
____________________________________________________________________________-->
  <indexterm zone="xfunc-optimization">
   <primary>optimization information</primary>
   <secondary>for functions</secondary>
  </indexterm>

<!--==========================orignal english content==========================
   <para>
    By default, a function is just a <quote>black box</quote> that the
    database system knows very little about the behavior of.  However,
    that means that queries using the function may be executed much less
    efficiently than they could be.  It is possible to supply additional
    knowledge that helps the planner optimize function calls.
   </para>
____________________________________________________________________________-->
   <para>
    默认情况下，函数只是一个<quote>black box</quote>，数据库系统对它的行为了解得很少。
    不过，这意味着使用函数的查询执行效率可能会低于它们的能力。可以提供额外的知识帮助计划器优化函数调用。
   </para>

<!--==========================orignal english content==========================
   <para>
    Some basic facts can be supplied by declarative annotations provided in
    the <xref linkend="sql-createfunction"/> command.  Most important of
    these is the function's <link linkend="xfunc-volatility">volatility
    category</link> (<literal>IMMUTABLE</literal>, <literal>STABLE</literal>,
    or <literal>VOLATILE</literal>); one should always be careful to
    specify this correctly when defining a function.
    The parallel safety property (<literal>PARALLEL
    UNSAFE</literal>, <literal>PARALLEL RESTRICTED</literal>, or
    <literal>PARALLEL SAFE</literal>) must also be specified if you hope
    to use the function in parallelized queries.
    It can also be useful to specify the function's estimated execution
    cost, and/or the number of rows a set-returning function is estimated
    to return.  However, the declarative way of specifying those two
    facts only allows specifying a constant value, which is often
    inadequate.
   </para>
____________________________________________________________________________-->
   <para>
    一些基本事实可以通过<xref linkend="sql-createfunction"/>命令中提供的声明性注释来提供。
    这里面最重要的是函数的<link linkend="xfunc-volatility">volatility category</link> (<literal>IMMUTABLE</literal>、 <literal>STABLE</literal>或 <literal>VOLATILE</literal>)；在定义函数时，要始终小心地正确指定这个。
    并行安全属性(<literal>PARALLEL UNSAFE</literal>、<literal>PARALLEL RESTRICTED</literal>或<literal>PARALLEL SAFE</literal>)也必须被指定，如果你希望在并行查询中使用该函数。
    指定函数的估算执行开销也会有作用，和/或集返回函数估计返回的行数。不过，指定这两个事实的声明方式只允许指定常数值，而这通常是不够的。
   </para>

<!--==========================orignal english content==========================
   <para>
    It is also possible to attach a <firstterm>planner support
    function</firstterm> to a SQL-callable function (called
    its <firstterm>target function</firstterm>), and thereby provide
    knowledge about the target function that is too complex to be
    represented declaratively.  Planner support functions have to be
    written in C (although their target functions might not be), so this is
    an advanced feature that relatively few people will use.
   </para>
____________________________________________________________________________-->
   <para>
    也可以将一个<firstterm>planner support function</firstterm> 附加到SQL-可调用函数（称为<firstterm>target function</firstterm>），
    从而提供关于目标函数的知识，该函数过于复杂而无法以声明方式表示。
    计划器支持函数必须写在 C 中（尽管它们的目标函数可以不是），所以这是一个高级功能，相对很少有人会使用。
   </para>

<!--==========================orignal english content==========================
   <para>
    A planner support function must have the SQL signature
<programlisting>
supportfn(internal) returns internal
</programlisting>
    It is attached to its target function by specifying
    the <literal>SUPPORT</literal> clause when creating the target function.
   </para>
____________________________________________________________________________-->
   <para>
    计划器支持函数必须具有SQL签名
<programlisting>
supportfn(internal) returns internal
</programlisting>
    当建立目标函数时，它通过指定<literal>SUPPORT</literal>子句附加到它的目标函数。
   </para>

<!--==========================orignal english content==========================
   <para>
    The details of the API for planner support functions can be found in
    file <filename>src/include/nodes/supportnodes.h</filename> in the
    <productname>PostgreSQL</productname> source code.  Here we provide
    just an overview of what planner support functions can do.
    The set of possible requests to a support function is extensible,
    so more things might be possible in future versions.
   </para>
____________________________________________________________________________-->
   <para>
    计划器支持函数的 API 的详细信息可以在 <productname>PostgreSQL</productname>源代码中的<filename>src/include/nodes/supportnodes.h</filename>文件中找到。
    这里我们提供了计划器支持函数的概述。支持函数的可能请求集合是可扩展的，所以在将来的版本中可能会有更多(功能)。
   </para>

<!--==========================orignal english content==========================
   <para>
    Some function calls can be simplified during planning based on
    properties specific to the function.  For example,
    <literal>int4mul(n, 1)</literal> could be simplified to
    just <literal>n</literal>.  This type of transformation can be
    performed by a planner support function, by having it implement
    the <literal>SupportRequestSimplify</literal> request type.
    The support function will be called for each instance of its target
    function found in a query parse tree.  If it finds that the particular
    call can be simplified into some other form, it can build and return a
    parse tree representing that expression.  This will automatically work
    for operators based on the function, too &mdash; in the example just
    given, <literal>n * 1</literal> would also be simplified to
    <literal>n</literal>.
    (But note that this is just an example; this particular
    optimization is not actually performed by
    standard <productname>PostgreSQL</productname>.)
    We make no guarantee that <productname>PostgreSQL</productname> will
    never call the target function in cases that the support function could
    simplify.  Ensure rigorous equivalence between the simplified
    expression and an actual execution of the target function.
   </para>
____________________________________________________________________________-->
   <para>
    在规划期间，根据指定函数的特性，一些函数调用可以进行简化。
    例如，<literal>int4mul(n, 1)</literal>可以被简化为<literal>n</literal>。
    这种类型的转换可以通过计划器支持函数执行，通过它实现<literal>SupportRequestSimplify</literal>请求类型。
    对于在查询解析树中找到其目标函数的每个实例，将调用支持函数。如果它发现特定的调用可以简化成某种其他窗体，它可以构建并返回表示该表达式的解析树。
    这将为基于函数的操作符自动工作，非常&mdash；在刚才的示例中，<literal>n * 1</literal>也将简化为<literal>n</literal>。
    （但注意这只是一个例子；这个特殊的优化实际上不是标准的<productname>PostgreSQL</productname>执行）。
    我们不保证<productname>PostgreSQL</productname>在支持函数能够简化的情况下，永远不会调用目标函数。 确保简化表达式与目标函数的实际执行之间严格等效。
   </para>

<!--==========================orignal english content==========================
   <para>
    For target functions that return <type>boolean</type>, it is often useful to estimate
    the fraction of rows that will be selected by a <literal>WHERE</literal> clause using that
    function.  This can be done by a support function that implements
    the <literal>SupportRequestSelectivity</literal> request type.
   </para>
____________________________________________________________________________-->
   <para>
    对于返回 <type>boolean</type> 的目标函数，估计使用该函数的 <literal>WHERE</literal> 子句将选择的行的比重通常会有用。
    这可以通过实现<literal>SupportRequestSelectivity</literal>请求类型的支持函数来完成。
   </para>

<!--==========================orignal english content==========================
   <para>
    If the target function's run time is highly dependent on its inputs,
    it may be useful to provide a non-constant cost estimate for it.
    This can be done by a support function that implements
    the <literal>SupportRequestCost</literal> request type.
   </para>
____________________________________________________________________________-->
   <para>
    如果目标函数的运行时间高度依赖于其输入，提供非固定开销估算可能很有用。这可以通过实现<literal>SupportRequestCost</literal>请求类型的支持函数来完成。
   </para>

<!--==========================orignal english content==========================
   <para>
    For target functions that return sets, it is often useful to provide
    a non-constant estimate for the number of rows that will be returned.
    This can be done by a support function that implements
    the <literal>SupportRequestRows</literal> request type.
   </para>
____________________________________________________________________________-->
   <para>
    对于返回集的目标函数，为提供要返回的行数的非常量估计通常很有用。这可以通过实现<literal>SupportRequestRows</literal>请求类型的支持函数来完成。
   </para>

<!--==========================orignal english content==========================
   <para>
    For target functions that return <type>boolean</type>, it may be possible to
    convert a function call appearing in <literal>WHERE</literal> into an indexable operator
    clause or clauses.  The converted clauses might be exactly equivalent
    to the function's condition, or they could be somewhat weaker (that is,
    they might accept some values that the function condition does not).
    In the latter case the index condition is said to
    be <firstterm>lossy</firstterm>; it can still be used to scan an index,
    but the function call will have to be executed for each row returned by
    the index to see if it really passes the <literal>WHERE</literal> condition or not.
    To create such conditions, the support function must implement
    the <literal>SupportRequestIndexCondition</literal> request type.
   </para>
____________________________________________________________________________-->
   <para>
    对于返回 <type>boolean</type>的目标函数，可以将<literal>WHERE</literal>中出现的函数调用转换为一个可索引操作符子句或多个子句。
    转换的子句可能与函数的条件完全相同，或者它们可能比较弱态一些(也就是说，它们可能接受函数条件所不接受的一些值)。
    在后一种情况下，索引条件被称作<firstterm>lossy</firstterm>；它仍然可用于扫描索引，但必须为索引返回的每一行执行函数调用，以看它是否真的通过 <literal>WHERE</literal>条件或没有。
    要建立这样的条件，支持函数必须实现<literal>SupportRequestIndexCondition</literal>需求类型。
   </para>
  </sect1>

Author: chegong18