update refresh_materialized_view.sgml &prepare_transaction.sgml

refresh_materialized_view.sgml
2019.12.15
将英文原文中的</>增加相应tag.

prepare_transaction.sgml
2019.12.15
将英文原文中的</>增加相应tag.

Author: chegong18

postgresql/doc/src/sgml/ref/prepare_transaction.sgml

@@ -90,7 +90,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
   <para>
    From the point of view of the issuing session, <command>PREPARE
-   TRANSACTION</command> is not unlike a <command>ROLLBACK</> command:
+   TRANSACTION</command> is not unlike a <command>ROLLBACK</command> command:
    after executing it, there is no active current transaction, and the
    effects of the prepared transaction are no longer visible.  (The effects
    will become visible again if the transaction is committed.)
@@ -106,7 +106,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
   <para>
    If the <command>PREPARE TRANSACTION</command> command fails for any
-   reason, it becomes a <command>ROLLBACK</>: the current transaction
+   reason, it becomes a <command>ROLLBACK</command>: the current transaction
    is canceled.
   </para>
 ____________________________________________________________________________-->
@@ -132,7 +132,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
      <para>
       An arbitrary identifier that later identifies this transaction for
-      <command>COMMIT PREPARED</> or <command>ROLLBACK PREPARED</>.
+      <command>COMMIT PREPARED</command> or <command>ROLLBACK PREPARED</command>.
       The identifier must be written as a string literal, and must be
       less than 200 bytes long.  It must not be the same as the identifier
       used for any currently prepared transaction.
@@ -157,12 +157,12 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
   <para>
-   <command>PREPARE TRANSACTION</> is not intended for use in applications
+   <command>PREPARE TRANSACTION</command> is not intended for use in applications
    or interactive sessions. Its purpose is to allow an external
    transaction manager to perform atomic global transactions across multiple
    databases or other transactional resources. Unless you're writing a
    transaction manager, you probably shouldn't be using <command>PREPARE
-   TRANSACTION</>.
+   TRANSACTION</command>.
   </para>
 ____________________________________________________________________________-->
   <para>
@@ -185,11 +185,11 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
   <para>
-   It is not currently allowed to <command>PREPARE</> a transaction that
+   It is not currently allowed to <command>PREPARE</command> a transaction that
    has executed any operations involving temporary tables or the session's
    temporary namespace, created any cursors <literal>WITH HOLD</literal>, or
    executed <command>LISTEN</command>, <command>UNLISTEN</command>, or
-   <command>NOTIFY</>.
+   <command>NOTIFY</command>.
    Those features are too tightly
    tied to the current session to be useful in a transaction to be prepared.
   </para>
@@ -204,13 +204,13 @@ ____________________________________________________________________________-->
 
 <!--==========================orignal english content==========================
   <para>
-   If the transaction modified any run-time parameters with <command>SET</>
-   (without the <literal>LOCAL</> option),
-   those effects persist after <command>PREPARE TRANSACTION</>, and will not
+   If the transaction modified any run-time parameters with <command>SET</command>
+   (without the <literal>LOCAL</literal> option),
+   those effects persist after <command>PREPARE TRANSACTION</command>, and will not
    be affected by any later <command>COMMIT PREPARED</command> or
    <command>ROLLBACK PREPARED</command>.  Thus, in this one respect
-   <command>PREPARE TRANSACTION</> acts more like <command>COMMIT</> than
-   <command>ROLLBACK</>.
+   <command>PREPARE TRANSACTION</command> acts more like <command>COMMIT</command> than
+   <command>ROLLBACK</command>.
   </para>
 ____________________________________________________________________________-->
   <para>
@@ -238,7 +238,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
    <para>
     It is unwise to leave transactions in the prepared state for a long time.
-    This will interfere with the ability of <command>VACUUM</> to reclaim
+    This will interfere with the ability of <command>VACUUM</command> to reclaim
     storage, and in extreme cases could cause the database to shut down
     to prevent transaction ID wraparound (see <xref
     linkend="vacuum-for-wraparound">).  Keep in mind also that the transaction
@@ -284,7 +284,7 @@ ____________________________________________________________________________-->
 <!--==========================orignal english content==========================
   <para>
    Prepare the current transaction for two-phase commit, using
-   <literal>foobar</> as the transaction identifier:
+   <literal>foobar</literal> as the transaction identifier:
 
 <programlisting>
 PREPARE TRANSACTION 'foobar';

postgresql/doc/src/sgml/ref/refresh_materialized_view.sgml

@@ -182,9 +182,9 @@ ____________________________________________________________________________-->
   <para>
    While the default index for future
    <xref linkend="sql-cluster">
-   operations is retained, <command>REFRESH MATERIALIZED VIEW</> does not
+   operations is retained, <command>REFRESH MATERIALIZED VIEW</command> does not
    order the generated rows based on this property. If you want the data
-   to be ordered upon generation, you must use an <literal>ORDER BY</>
+   to be ordered upon generation, you must use an <literal>ORDER BY</literal>
    clause in the backing query.
   </para>
 ____________________________________________________________________________-->