Fix orthotypographical mistake
authorAlvaro Herrera
Tue, 12 Mar 2013 14:57:22 +0000 (11:57 -0300)
committerAlvaro Herrera
Tue, 12 Mar 2013 15:28:50 +0000 (12:28 -0300)
Apparently I lost some of the edits I had done on this page for commit
0ac5ad5134.

Per note from Etsuro Fujita, although I didn't use his patch.

Make some of the wording in the affected section a bit more complete,
too.

doc/src/sgml/ref/select.sgml

index 0f9d52753d832fa458aca563fa2bfcf558120818..1d3f854b64cec009ff3e0ed2327b351cffb9309d 100644 (file)
@@ -1200,7 +1200,7 @@ FETCH { FIRST | NEXT } [ count ] {
   
 
   
-   FOR UPDATE, FOR NO KEY UPDATE/FOR SHARE/FOR KEY SHARE Clauses
+   The Locking Clause
 
    
     FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE
@@ -1210,30 +1210,19 @@ FETCH { FIRST | NEXT } [ count ] {
    
 
    
-    The FOR UPDATE clause has this form:
-
-FOR UPDATE [ OF table_name [, ...] ] [ NOWAIT ]
-
-   
+    The locking clause has the general form
 
-   
-    The FOR NO KEY UPDATE clause has this form:
 
-FOR NO KEY UPDATE [ OF table_name [, ...] ] [ NOWAIT ]
+FOR lock_strength [ OF table_name [, ...] ] [ NOWAIT ]
 
-   
 
-   
-    The closely related FOR SHARE clause has this form:
-
-FOR SHARE [ OF table_name [, ...] ] [ NOWAIT ]
-
-   
+    where lock_strength can be one of
 
-   
-    Similarly, the FOR KEY SHARE clause has this form:
 
-FOR KEY SHARE [ OF table_name [, ...] ] [ NOWAIT ]
+UPDATE
+NO KEY UPDATE
+SHARE
+KEY SHARE
 
    
 
@@ -1245,6 +1234,7 @@ FOR KEY SHARE [ OF table_name [, ..
     other transactions that attempt UPDATE,
     DELETE,
     SELECT FOR UPDATE,
+    SELECT FOR NO KEY UPDATE,
     SELECT FOR SHARE or
     SELECT FOR KEY SHARE
     of these rows will be blocked until the current transaction ends.
@@ -1270,15 +1260,17 @@ FOR KEY SHARE [ OF table_name [, ..
     FOR NO KEY UPDATE behaves similarly, except that the lock
     acquired is weaker: this lock will not block
     SELECT FOR KEY SHARE commands that attempt to acquire
-    a lock on the same rows.
+    a lock on the same rows. This lock mode is also acquired by any
+    UPDATE that does not acquire a FOR UPDATE lock.
    
 
    
     FOR SHARE behaves similarly, except that it
     acquires a shared rather than exclusive lock on each retrieved
     row.  A shared lock blocks other transactions from performing
-    UPDATEDELETE, or SELECT
-    FOR UPDATE on these rows, but it does not prevent them
+    UPDATEDELETESELECT
+    FOR UPDATE or SELECT FOR NO KEY UPDATE
+    on these rows, but it does not prevent them
     from performing SELECT FOR SHARE or
     SELECT FOR KEY SHARE.
    
@@ -1290,8 +1282,8 @@ FOR KEY SHARE [ OF table_name [, ..
     not SELECT FOR NO KEY UPDATE.  A key-shared
     lock blocks other transactions from performing DELETE
     or any UPDATE that changes the key values, but not
-    other UPDATE, and neither it does prevent
-    SELECT FOR UPDATE, SELECT FOR SHARE, or
+    other UPDATE, and neither does it prevent
+    SELECT FOR NO KEY UPDATE, SELECT FOR SHARE, or
     SELECT FOR KEY SHARE.
    
 
@@ -1382,7 +1374,7 @@ UPDATE mytable SET ... WHERE key = 1;
 ROLLBACK TO s;
 
    would fail to preserve the FOR UPDATE lock after the
-   ROLLBACK.  This has been fixed in release 9.2.
+   ROLLBACK TO.  This has been fixed in release 9.3.