diff --git a/postgresql/doc/src/sgml/ddl.sgml b/postgresql/doc/src/sgml/ddl.sgml
index 55e738f1..0f011c95 100644
--- a/postgresql/doc/src/sgml/ddl.sgml
+++ b/postgresql/doc/src/sgml/ddl.sgml
@@ -6234,7 +6234,7 @@ ____________________________________________________________________________-->
   </para>
 ____________________________________________________________________________-->
   <para>
-   继承的查询仅在附表上执行访问权限检查。例如，在<structname>cities</structname>表上授予<literal>UPDATE</literal>权限也隐含着通过<structname>cities</structname>访问时在<structname>capitals</structname>表中更新行的权限。
+   继承的查询仅在父表上执行访问权限检查。例如，在<structname>cities</structname>表上授予<literal>UPDATE</literal>权限也隐含着通过<structname>cities</structname>访问时在<structname>capitals</structname>表中更新行的权限。
    这保留了数据（也）在父表中的样子。但是如果没有额外的授权，则不能直接更新<structname>capitals</structname>表。
    以类似的方式，父表的行安全性策略（见<xref linkend="ddl-rowsecurity"/>）适用于继承查询期间来自于子表的行。
    只有当子表在查询中被明确提到时，其策略（如果有）才会被应用，在那种情况下，附着在其父表上的任何策略都会被忽略。
diff --git a/postgresql/doc/src/sgml/rules.sgml b/postgresql/doc/src/sgml/rules.sgml
index 125cf6c9..d2aebe4f 100644
--- a/postgresql/doc/src/sgml/rules.sgml
+++ b/postgresql/doc/src/sgml/rules.sgml
@@ -3790,7 +3790,7 @@ ____________________________________________________________________________-->
 CREATE VIEW phone_number WITH (security_barrier) AS
     SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';
 </programlisting>
-    Views created with the 使用<literal>security_barrier</literal>创建的视图的性能会远差于没有使用该选项的视图。通常，没有办法来避免这种现状：如果最快的候选计划可能在安全性上折衷，它就必须被拒绝。出于该原因，这个选在在默认情况下是没有启用的。
+    使用<literal>security_barrier</literal>创建的视图的性能会远差于没有使用该选项的视图。通常，没有办法来避免这种现状：如果最快的候选计划可能在安全性上折衷，它就必须被拒绝。出于该原因，这个选在在默认情况下是没有启用的。
 </para>
 
 <!--==========================orignal english content==========================