diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 12f7c3706e..03c1fa03bf 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1400,13 +1400,33 @@ ALTER TABLE products RENAME TO items;
privilege
+
+ owner
+
+
+
+ GRANT
+
+
+
+ REVOKE
+
+
- When you create a database object, you become its owner. By
- default, only the owner of an object can do anything with the
- object. In order to allow other users to use it,
- privileges must be granted. (However,
- users that have the superuser attribute can always
- access any object.)
+ When an object is created, it is assigned an owner. The
+ owner is normally the role that executed the creation statement.
+ For most kinds of objects, the initial state is that only the owner
+ (or a superuser) can do anything with the object. To allow
+ other roles to use it, privileges must be
+ granted.
+ There are several different kinds of privilege: SELECT,
+ INSERT, UPDATE, DELETE,
+ TRUNCATE, REFERENCES, TRIGGER,
+ CREATE, CONNECT, TEMPORARY,
+ EXECUTE, and USAGE.
+ For more information on the different types of privileges supported by
+ PostgreSQL, see the
+ reference page.
@@ -1429,14 +1449,14 @@ ALTER TABLE products RENAME TO items;
the owner only.
-
-
- To change the owner of a table, index, sequence, or view, use the
-
- command. There are corresponding ALTER commands for
- other object types.
-
-
+
+ An object can be assigned to a new owner with an ALTER
+ command of the appropriate kind for the object, e.g. . Superusers can always do
+ this; ordinary roles can only do it if they are both the current owner
+ of the object (or a member of the owning role) and a member of the new
+ owning role.
+
To assign privileges, the GRANT command is
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 2830aec49c..6a528270ee 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -1,7 +1,7 @@
- Database Roles and Privileges
+ Database Roles
PostgreSQL manages database access permissions
@@ -22,10 +22,9 @@
- This chapter describes how to create and manage roles and introduces
- the privilege system. More information about the various types of
- database objects and the effects of privileges can be found in
- .
+ This chapter describes how to create and manage roles.
+ More information about the effects of privileges on various database
+ objects can be found in .
@@ -282,81 +281,6 @@ ALTER ROLE myname SET enable_indexscan TO off;
-
- Privileges
-
-
- privilege
-
-
-
- owner
-
-
-
- GRANT
-
-
-
- REVOKE
-
-
-
- When an object is created, it is assigned an owner. The
- owner is normally the role that executed the creation statement.
- For most kinds of objects, the initial state is that only the owner
- (or a superuser) can do anything with the object. To allow
- other roles to use it, privileges must be
- granted.
- There are several different kinds of privilege: SELECT,
- INSERT, UPDATE, DELETE,
- TRUNCATE, REFERENCES, TRIGGER,
- CREATE, CONNECT, TEMPORARY,
- EXECUTE, and USAGE.
- For more information on the different types of privileges supported by
- PostgreSQL, see the
- reference page.
-
-
-
- To assign privileges, the GRANT command is
- used. So, if joe is an existing role, and
- accounts is an existing table, the privilege to
- update the table can be granted with:
-
-GRANT UPDATE ON accounts TO joe;
-
- The special name PUBLIC can
- be used to grant a privilege to every role on the system. Writing
- ALL in place of a specific privilege specifies that all
- privileges that apply to the object will be granted.
-
-
-
- To revoke a privilege, use the fittingly named
- command:
-
-REVOKE ALL ON accounts FROM PUBLIC;
-
-
-
-
- The special privileges of an object's owner (i.e., the right to modify
- or destroy the object) are always implicit in being the owner,
- and cannot be granted or revoked. But the owner can choose
- to revoke his own ordinary privileges, for example to make a
- table read-only for himself as well as others.
-
-
-
- An object can be assigned to a new owner with an ALTER
- command of the appropriate kind for the object. Superusers can always do
- this; ordinary roles can only do it if they are both the current owner
- of the object (or a member of the owning role) and a member of the new
- owning role.
-
-
-
Role Membership