Doc: undo mistaken adjustment to LOCK TABLE docs in back branches.

tglsfdc · tglsfdc · commit 583fcf2f5759 · 2020-11-06T12:14:46.000-05:00
Commits 59ab4ac et al mistakenly copied-and-pasted some text about how LOCK on a view recurses to referenced tables into pre-v11 branches, which in fact don't do that. Undo that, and instead state clearly that they don't. (I also chose to add a note that this behavior changed in v11. We usually don't back-patch such statements, but since it's easy to add the warning now, might as well.) Noted while considering followup fixes for bug #16703. Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
@@ -117,8 +117,13 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [ * ]
       table is locked. If <literal>ONLY</literal> is not specified, the table and all
       its descendant tables (if any) are locked.  Optionally, <literal>*</literal>
       can be specified after the table name to explicitly indicate that
-      descendant tables are included.  When locking a view, all relations appearing
-      in the view definition are locked, regardless of <literal>ONLY</literal>.
+      descendant tables are included.
+     </para>
+
+     <para>
+      Locking a view locks only the view object itself, not any referenced
+      relations.  (Note that this behavior is different
+      in <productname>PostgreSQL</productname> v11 and later.)
      </para>
 
      <para>
