Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
48d25bac
Commit
48d25bac
authored
14 years ago
by
Bruce Momjian
Browse files
Options
Downloads
Patches
Plain Diff
Merge two documentation permission chapters into a single chapter.
parent
087bd179
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/src/sgml/ddl.sgml
+34
-14
34 additions, 14 deletions
doc/src/sgml/ddl.sgml
doc/src/sgml/user-manag.sgml
+4
-80
4 additions, 80 deletions
doc/src/sgml/user-manag.sgml
with
38 additions
and
94 deletions
doc/src/sgml/ddl.sgml
+
34
−
14
View file @
48d25bac
...
...
@@ -1400,13 +1400,33 @@ ALTER TABLE products RENAME TO items;
<see>privilege</see>
</indexterm>
<indexterm zone="ddl-priv">
<primary>owner</primary>
</indexterm>
<indexterm zone="ddl-priv">
<primary>GRANT</primary>
</indexterm>
<indexterm zone="ddl-priv">
<primary>REVOKE</primary>
</indexterm>
<para>
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,
<firstterm>privileges</firstterm> 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, <firstterm>privileges</firstterm> must be
granted.
There are several different kinds of privilege: <literal>SELECT</>,
<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>,
<literal>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
<literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>,
<literal>EXECUTE</>, and <literal>USAGE</>.
For more information on the different types of privileges supported by
<productname>PostgreSQL</productname>, see the
<xref linkend="sql-grant"> reference page.
</para>
<para>
...
...
@@ -1429,14 +1449,14 @@ ALTER TABLE products RENAME TO items;
the owner only.
</para>
<
note
>
<para
>
To change the owner of a table, index, sequence, or view, use the
<xref
linkend="sql-altertable">
command. There ar
e c
o
rre
sponding <literal>ALTER</> commands fo
r
othe
r
object
types.
</para>
</
note
>
<
para
>
An object can be assigned to a new owner with an <command>ALTER</command
>
command of the appropriate kind for the object, e.g. <xref
linkend="sql-altertable">
. Superusers can always do
this; ordinary roles can only do it if they are both th
e c
u
rre
nt owne
r
o
f
the object
(or a member of the owning role) and a member of the new
owning role.
</
para
>
<para>
To assign privileges, the <command>GRANT</command> command is
...
...
This diff is collapsed.
Click to expand it.
doc/src/sgml/user-manag.sgml
+
4
−
80
View file @
48d25bac
<!-- doc/src/sgml/user-manag.sgml -->
<chapter id="user-manag">
<title>Database Roles
and Privileges
</title>
<title>Database Roles</title>
<para>
<productname>PostgreSQL</productname> manages database access permissions
...
...
@@ -22,10 +22,9 @@
</para>
<para>
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
<xref linkend="ddl">.
This chapter describes how to create and manage roles.
More information about the effects of privileges on various database
objects can be found in <xref linkend="ddl-priv">.
</para>
<sect1 id="database-roles">
...
...
@@ -282,81 +281,6 @@ ALTER ROLE myname SET enable_indexscan TO off;
</para>
</sect1>
<sect1 id="privileges">
<title>Privileges</title>
<indexterm zone="privileges">
<primary>privilege</primary>
</indexterm>
<indexterm zone="privileges">
<primary>owner</primary>
</indexterm>
<indexterm zone="privileges">
<primary>GRANT</primary>
</indexterm>
<indexterm zone="privileges">
<primary>REVOKE</primary>
</indexterm>
<para>
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, <firstterm>privileges</firstterm> must be
granted.
There are several different kinds of privilege: <literal>SELECT</>,
<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>,
<literal>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>,
<literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>,
<literal>EXECUTE</>, and <literal>USAGE</>.
For more information on the different types of privileges supported by
<productname>PostgreSQL</productname>, see the
<xref linkend="sql-grant"> reference page.
</para>
<para>
To assign privileges, the <command>GRANT</command> command is
used. So, if <literal>joe</literal> is an existing role, and
<literal>accounts</literal> is an existing table, the privilege to
update the table can be granted with:
<programlisting>
GRANT UPDATE ON accounts TO joe;
</programlisting>
The special name <literal>PUBLIC</literal> can
be used to grant a privilege to every role on the system. Writing
<literal>ALL</literal> in place of a specific privilege specifies that all
privileges that apply to the object will be granted.
</para>
<para>
To revoke a privilege, use the fittingly named
<xref linkend="sql-revoke"> command:
<programlisting>
REVOKE ALL ON accounts FROM PUBLIC;
</programlisting>
</para>
<para>
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.
</para>
<para>
An object can be assigned to a new owner with an <command>ALTER</command>
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.
</para>
</sect1>
<sect1 id="role-membership">
<title>Role Membership</title>
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment