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
This commit is contained in:
Tom Lane 2020-11-06 12:14:36 -05:00
parent 9d878d7fee
commit 33862cb9c1
1 changed files with 7 additions and 2 deletions

View File

@ -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>