translate finished

Author: messon

postgresql/doc/src/sgml/sources.sgml

@@ -187,7 +187,7 @@ ____________________________________________________________________________-->
     message text.  In addition there are optional elements, the most
     common of which is an error identifier code that follows the SQL spec's
     SQLSTATE conventions.
-    <function>ereport</function> itself is just a shell macro, that exists
+    <function>ereport</function> itself is just a shell macro that exists
     mainly for the syntactic convenience of making message generation
     look like a single function call in the C source code.  The only parameter
     accepted directly by <function>ereport</function> is the severity level.
@@ -414,6 +414,14 @@ ____________________________________________________________________________-->
      <function>errmsg</function>.
     </para>
    </listitem>
+   <listitem>
+    <para>
+     <function>errhint_plural(const char *fmt_singular, const char *fmt_plural,
+     unsigned long n, ...)</function> is like <function>errhint</function>, but with
+     support for various plural forms of the message.
+     For more information see <xref linkend="nls-guidelines"/>.
+    </para>
+   </listitem>
    <listitem>
     <para>
      <function>errcontext(const char *msg, ...)</function> is not normally called
@@ -574,6 +582,12 @@ ____________________________________________________________________________-->
      <function>errhint(const char *msg, ...)</function>提供一个可选的<quote>hint</quote>消息，它被用来提供关于如何修复该问题的建议。该消息字符串以和<function>errmsg</function>相同的方式处理。
     </para>
    </listitem>
+   <listitem>
+    <para>
+     <function>errhint_plural(const char *fmt_singular, const char *fmt_plural,
+     unsigned long n, ...)</function>与<function>errhint</function>相似，但是支持多种复数形式的消息。详见<xref linkend="nls-guidelines"/>。
+    </para>
+   </listitem>
    <listitem>
     <para>
      <function>errcontext(const char *msg, ...)</function>通常不会被直接从一个<function>ereport</function>消息站点调用，它被用在<literal>error_context_stack</literal>回调函数中来提供错误发生的上下文，例如一个 PL 函数中的当前位置。该消息字符串以和<function>errmsg</function>相同的方式处理。不同于其他辅助函数，在每次<function>ereport</function>调用中可以多次调用这个函数，这样提供的连续的字符串将被用单独的新行串接在一起。
@@ -1409,6 +1423,24 @@ ____________________________________________________________________________-->
    </para>
   </formalpara>
 
+  <formalpara>
+<!--==========================orignal english content==========================
+    <title>Non-negative</title>
+____________________________________________________________________________-->
+    <title>Non-negative</title>
+<!--==========================orignal english content==========================
+    <para>
+     Avoid <quote>non-negative</quote> as it is ambiguous
+     about whether it accepts zero.  It's better to use
+     <quote>greater than zero</quote> or
+     <quote>greater than or equal to zero</quote>.
+    </para>
+____________________________________________________________________________-->
+   <para>
+    避免<quote>non-negative</quote>，因为它不能清楚表达是否接受0。最好使用<quote>greater than zero</quote>或<quote>greater than or equal to zero</quote>。
+   </para>
+  </formalpara>
+
   </simplesect>
 
   <simplesect>

postgresql/doc/src/sgml/syntax.sgml

@@ -1429,15 +1429,15 @@ ____________________________________________________________________________-->
    <para>
     When working with non-SQL-standard operator names, you will usually
     need to separate adjacent operators with spaces to avoid ambiguity.
-    For example, if you have defined a left unary operator named <literal>@</literal>,
+    For example, if you have defined a prefix operator named <literal>@</literal>,
     you cannot write <literal>X*@Y</literal>; you must write
     <literal>X* @Y</literal> to ensure that
     <productname>PostgreSQL</productname> reads it as two operator names
     not one.
    </para>
 ____________________________________________________________________________-->
    <para>
-    当使用非 SQL 标准的操作符名时，你通常需要用空格分隔相邻的操作符来避免歧义。例如，如果你定义了一个名为<literal>@</literal>的左一元操作符，你不能写<literal>X*@Y</literal>，你必须写<literal>X* @Y</literal>来确保<productname>PostgreSQL</productname>把它读作两个操作符名而不是一个。
+    当使用非 SQL 标准的操作符名时，你通常需要用空格分隔相邻的操作符来避免歧义。例如，如果你定义了一个名为<literal>@</literal>的前缀操作符，你不能写<literal>X*@Y</literal>，你必须写<literal>X* @Y</literal>来确保<productname>PostgreSQL</productname>把它读作两个操作符名而不是一个。
    </para>
   </sect2>
 
@@ -1950,11 +1950,7 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
      cases, these changes will result in no behavioral change, or perhaps
      in <quote>no such operator</quote> failures which can be resolved by adding
      parentheses.  However there are corner cases in which a query might
-     change behavior without any parsing error being reported.  If you are
-     concerned about whether these changes have silently broken something,
-     you can test your application with the configuration
-     parameter <xref linkend="guc-operator-precedence-warning"/> turned on
-     to see if any warnings are logged.
+     change behavior without any parsing error being reported.
     </para>
 ____________________________________________________________________________-->
     <para>
@@ -1967,9 +1963,7 @@ ____________________________________________________________________________-->
      逻辑上等价的结构不一致的处理，这些规则也得到了修改。在大部分情况下，
      这些变化不会导致行为上的变化，或者可能会产生<quote>no such operator</quote>
      错误，但可以通过增加圆括号解决。不过在一些极端情况中，查询可能在
-     没有被报告解析错误的情况下发生行为的改变。如果你发觉这些改变悄悄地
-     破坏了一些事情，可以打开<xref linkend="guc-operator-precedence-warning"/>
-     配置参数，然后测试你的应用看看有没有一些警告被记录。
+     没有被报告解析错误的情况下发生行为的改变。
     </para>
    </note>
   </sect2>
@@ -2566,7 +2560,7 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
    <para>
-    There are three possible syntaxes for an operator invocation:
+    There are two possible syntaxes for an operator invocation:
     <simplelist>
      <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable> (binary infix operator)</member>
      <member><replaceable>operator</replaceable> <replaceable>expression</replaceable> (unary prefix operator)</member>
@@ -2586,11 +2580,10 @@ ____________________________________________________________________________-->
    </para>
 ____________________________________________________________________________-->
    <para>
-    对于一次操作符调用，有三种可能的语法：
+    对于一次操作符调用，有两种可能的语法：
     <simplelist>
      <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable>（二元中缀操作符）</member>
      <member><replaceable>operator</replaceable> <replaceable>expression</replaceable>（一元前缀操作符）</member>
-     <member><replaceable>expression</replaceable> <replaceable>operator</replaceable>（一元后缀操作符）</member>
     </simplelist>
     其中<replaceable>operator</replaceable>记号遵循<xref linkend="sql-syntax-operators"/>的语法规则，或者是关键词<token>AND</token>、<token>OR</token>和<token>NOT</token>之一，或者是一个如下形式的受限定操作符名：
 <synopsis>

postgresql/doc/src/sgml/typeconv.sgml

@@ -68,13 +68,13 @@ has an associated data type which determines its behavior and allowed usage.
 <productname>PostgreSQL</productname> has an extensible type system that is
 more general and flexible than other <acronym>SQL</acronym> implementations.
 Hence, most type conversion behavior in <productname>PostgreSQL</productname>
-is governed by general rules rather than by <foreignphrase>ad hoc</foreignphrase>
+is governed by general rules rather than by ad hoc
 heuristics.  This allows the use of mixed-type expressions even with
 user-defined types.
 </para>
 ____________________________________________________________________________-->
 <para>
-<acronym>SQL</acronym>是一种强类型语言。也就是说，每个数据项都有一个相关的数据类型，数据类型决定其行为和允许的用法。 <productname>PostgreSQL</productname>有一个可扩展的类型系统，该系统比其它<acronym>SQL</acronym>实现更具通用和灵活。因而，<productname>PostgreSQL</productname>中大多数类型转换行为是由通用规则来管理的，而不是<foreignphrase>ad hoc</foreignphrase>启发式规则。这种做法允许使用混合类型表达式，即便是其中包含用户定义的类型。
+<acronym>SQL</acronym>是一种强类型语言。也就是说，每个数据项都有一个相关的数据类型，数据类型决定其行为和允许的用法。 <productname>PostgreSQL</productname>有一个可扩展的类型系统，该系统比其它<acronym>SQL</acronym>实现更具通用和灵活。因而，<productname>PostgreSQL</productname>中大多数类型转换行为是由通用规则来管理的，而不是特定的启发式规则。这种做法允许使用混合类型表达式，即便是其中包含用户定义的类型。
 </para>
 
 <!--==========================orignal english content==========================
@@ -146,8 +146,8 @@ Operators
 <listitem>
 <para>
 <productname>PostgreSQL</productname> allows expressions with
-prefix and postfix unary (one-argument) operators,
-as well as binary (two-argument) operators.  Like functions, operators can
+prefix (one-argument) operators,
+as well as infix (two-argument) operators.  Like functions, operators can
 be overloaded, so the same problem of selecting the right operator
 exists.
 </para>
@@ -206,7 +206,7 @@ ____________________________________________________________________________-->
 </term>
 <listitem>
 <para>
-<productname>PostgreSQL</productname>允许带有前缀和后缀一元（单目）操作符的表达式，也允许二元（两个参数）操作符。像函数一样，操作符也可以被重载，因此操作符的选择也有同样的问题。
+<productname>PostgreSQL</productname>允许带有前缀（单目）操作符的表达式，也允许中缀（两个参数）操作符。像函数一样，操作符也可以被重载，因此操作符的选择也有同样的问题。
 </para>
 </listitem>
 </varlistentry>
@@ -445,12 +445,12 @@ ____________________________________________________________________________-->
 <para>
 If one argument of a binary operator invocation is of the <type>unknown</type> type,
 then assume it is the same type as the other argument for this check.
-Invocations involving two <type>unknown</type> inputs, or a unary operator
+Invocations involving two <type>unknown</type> inputs, or a prefix operator
 with an <type>unknown</type> input, will never find a match at this step.
 </para>
 ____________________________________________________________________________-->
 <para>
-如果一个二元操作符调用中的一个参数是<type>unknown</type>类型，则在本次检查中假设它与另一个参数类型相同。 对于涉及两个<type>unknown</type>输入的调用或者带有一个<type>unknown</type>输入的一元操作符，在这一步将永远找不到一个匹配。
+如果一个二元操作符调用中的一个参数是<type>unknown</type>类型，则在本次检查中假设它与另一个参数类型相同。 对于涉及两个<type>unknown</type>输入的调用或者带有一个<type>unknown</type>输入的前缀操作符，在这一步将永远找不到一个匹配。
 </para>
 </step>
 <step id="op-resol-exact-domain" performance="optional">

postgresql/doc/src/sgml/uuid-ossp.sgml

@@ -49,15 +49,16 @@ ____________________________________________________________________________-->
   <para>
    <xref linkend="uuid-ossp-functions"/> shows the functions available to
    generate UUIDs.
-   The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and RFC
-   4122 specify four algorithms for generating UUIDs, identified by the
+   The relevant standards ITU-T Rec. X.667, ISO/IEC 9834-8:2005, and
+   <ulink url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink>
+   specify four algorithms for generating UUIDs, identified by the
    version numbers 1, 3, 4, and 5.  (There is no version 2 algorithm.)
    Each of these algorithms could be suitable for a different set of
    applications.
   </para>
 ____________________________________________________________________________-->
   <para>
-   <xref linkend="uuid-ossp-functions"/>展示了可用来产生 UUID 的函数。相关标准 ITU-T Rec. X.667、ISO/IEC 9834-8:2005 以及 RFC 4122 指定了四种用于产生 UUID 的算法，分别用版本号 1、3、4、5 标识（没有版本 2 的算法）。这些算法中的每一个都适合于不同的应用集合。
+   <xref linkend="uuid-ossp-functions"/>展示了可用来产生 UUID 的函数。相关标准 ITU-T Rec. X.667、ISO/IEC 9834-8:2005 以及<ulink url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink>指定了四种用于产生 UUID 的算法，分别用版本号 1、3、4、5 标识（没有版本 2 的算法）。这些算法中的每一个都适合于不同的应用集合。
   </para>
 
   <table id="uuid-ossp-functions">