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

Commits 59ab4ac32 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
index 7f40177129c0d8d5aa06b28ce5b16fb2044b4dcb..9b33ddc637c3bc735cabcf0b19d87dd58c5fa3c3 100644 (file)
--- 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>