Undo some poorly-thought-out "proofreading improvements".

Per Tatsuhito Kasahara.

diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 16130b6191c59d51a5a2016fedb850712b871471..5cdbe9554c8c26e3872f9a1e1693275005d91638 100644 (file)
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -129,7 +129,7 @@ SELECT rolname FROM pg_roles;
    is determined by the client authentication setup, as explained in
    . (Thus, a client is not
    limited to connect as the role matching
-   its operating system user, just as a person's login name 
+   its operating system user, just as a person's login name
    need not match her real name.)  Since the role
    identity determines the set of privileges available to a connected
    client, it is important to carefully configure privileges when setting up
@@ -219,7 +219,7 @@ CREATE USER name;
         make use of passwords. Database passwords are separate from
         operating system passwords. Specify a password upon role
         creation with CREATE ROLE
-        name PASSWORD 'string'. 
+        name PASSWORD 'string'.
        
       
      
@@ -249,11 +249,11 @@ CREATE USER name;
    want to disable index scans (hint: not a good idea) anytime you
    connect, you can use:
 
-ALTER ROLE myname SET statement_timeout = '5min';
+ALTER ROLE myname SET enable_indexscan TO off;
 
    This will save the setting (but not set it immediately).  In
    subsequent connections by this role it will appear as though
-   SET statement_timeout = '5min' had been executed
+   SET enable_indexscan TO off had been executed
    just before the session started.
    You can still alter this setting during the session; it will only
    be the default. To remove a role-specific default setting, use
@@ -387,10 +387,10 @@ REVOKE group_role FROM role1
    database session has access to the privileges of the group role rather
    than the original login role, and any database objects created are
    considered owned by the group role not the login role.  Second, member
-   roles that have the INHERIT attribute automatically inherit the
-   privileges of roles of which they are members, including their
-   INHERIT attributes.  As an example, suppose we have
-   done:
+   roles that have the INHERIT attribute automatically have use
+   of the privileges of roles of which they are members, including any
+   privileges inherited by those roles.
+   As an example, suppose we have done:
 
 CREATE ROLE joe LOGIN INHERIT;
 CREATE ROLE admin NOINHERIT;