From 33862cb9c13a9d5c53e887bea4909415e73be634 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 6 Nov 2020 12:14:36 -0500 Subject: [PATCH] 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 --- doc/src/sgml/ref/lock.sgml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml index 7f40177129..9b33ddc637 100644 --- a/doc/src/sgml/ref/lock.sgml +++ b/doc/src/sgml/ref/lock.sgml @@ -117,8 +117,13 @@ LOCK [ TABLE ] [ ONLY ] name [ * ] table is locked. If ONLY is not specified, the table and all its descendant tables (if any) are locked. Optionally, * 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 ONLY. + descendant tables are included. + + + + Locking a view locks only the view object itself, not any referenced + relations. (Note that this behavior is different + in PostgreSQL v11 and later.)