From: Robert Haas <rhaas@postgresql.org>
Date: Fri, 19 Sep 2014 17:07:24 +0000 (-0400)
Subject: doc: Use <literal> and all-caps for READ COMMITTED isolation level.
X-Git-Tag: REL9_5_ALPHA1~1451
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a92b5f969bed9796bcb3c321e7be4124a4533067;p=postgresql

doc: Use <literal> and all-caps for READ COMMITTED isolation level.

The documentation overall is not entirely consistent about how we do
this, but this is consistent with other usages within lock.sgml.

Etsuro Fujita
---

diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index 26e424b63e..913afe76dd 100644
--- a/doc/src/sgml/ref/lock.sgml
+++ b/doc/src/sgml/ref/lock.sgml
@@ -51,9 +51,9 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [ * ]
    restrictive lock mode possible. <command>LOCK TABLE</command>
    provides for cases when you might need more restrictive locking.
    For example, suppose an application runs a transaction at the
-   Read Committed isolation level and needs to ensure that data in a
-   table remains stable for the duration of the transaction. To
-   achieve this you could obtain <literal>SHARE</> lock mode over the
+   <literal>READ COMMITTED</> isolation level and needs to ensure that
+   data in a table remains stable for the duration of the transaction.
+   To achieve this you could obtain <literal>SHARE</> lock mode over the
    table before querying. This will prevent concurrent data changes
    and ensure subsequent reads of the table see a stable view of
    committed data, because <literal>SHARE</> lock mode conflicts with