doc: PG 16 relnotes: clarify LOCK TABLE description
authorBruce Momjian
Thu, 31 Aug 2023 19:14:18 +0000 (15:14 -0400)
committerBruce Momjian
Thu, 31 Aug 2023 19:14:18 +0000 (15:14 -0400)
Backpatch-through: 16 only

doc/src/sgml/release-16.sgml

index 2eb172eaa63efc4270f05de9dea62df606e5eb81..9816012631c4712f222be7660ae10f53220fb76c 100644 (file)
@@ -948,14 +948,15 @@ Author: Jeff Davis 
        
 
        
-        Previously the ability to perform LOCK
-        TABLE at various lock levels was bound to
-        specific query-type permissions.  For example, 
+        Previously a user's ability to perform LOCK
+        TABLE at various lock levels was limited to the
+        lock levels required by the commands they had permission
+        to execute on the table.  For example, someone with 
         linkend="sql-update">UPDATE
-        could perform all lock levels except
-        ACCESS SHARE, which required 
-        linkend="sql-select">SELECT permissions.
-        Now UPDATE can issue all lock levels.  MORE?
+        permission could perform all lock levels except ACCESS
+        SHARE, even though it was a lesser lock level.  Now users
+        can issue lesser lock levels if they already have permission for
+        greater lock levels.