mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-05 16:29:19 +02:00
Further improve documentation of the role-dropping process.
In commit 1ea0c73c2
I added a section to user-manag.sgml about how to drop
roles that own objects; but as pointed out by Stephen Frost, I neglected
that shared objects (databases or tablespaces) may need special treatment.
Fix that. Back-patch to supported versions, like the previous patch.
This commit is contained in:
parent
16e8e62d27
commit
d3762fe6c2
@ -431,17 +431,23 @@ ALTER TABLE bobs_table OWNER TO alice;
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
Alternatively, the <xref linkend="sql-reassign-owned"> command can be
|
Alternatively, the <xref linkend="sql-reassign-owned"> command can be
|
||||||
used to reassign ownership of all objects owned by the role-to-be-dropped
|
used to reassign ownership of all objects owned by the role-to-be-dropped
|
||||||
to a single other role. Because <command>REASSIGN OWNED</> can only
|
to a single other role. Because <command>REASSIGN OWNED</> cannot access
|
||||||
access objects in the current database, it is necessary to run it in each
|
objects in other databases, it is necessary to run it in each database
|
||||||
database that contains objects owned by the role.
|
that contains objects owned by the role. (Note that the first
|
||||||
|
such <command>REASSIGN OWNED</> will change the ownership of any
|
||||||
|
shared-across-databases objects, that is databases or tablespaces, that
|
||||||
|
are owned by the role-to-be-dropped.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Once any valuable objects have been transferred to new owners, any
|
Once any valuable objects have been transferred to new owners, any
|
||||||
remaining objects owned by the role-to-be-dropped can be dropped with
|
remaining objects owned by the role-to-be-dropped can be dropped with
|
||||||
the <xref linkend="sql-drop-owned"> command. Again, this command can
|
the <xref linkend="sql-drop-owned"> command. Again, this command cannot
|
||||||
only access objects in the current database, so it is necessary to run it
|
access objects in other databases, so it is necessary to run it in each
|
||||||
in each database that contains objects owned by the role.
|
database that contains objects owned by the role. Also, <command>DROP
|
||||||
|
OWNED</> will not drop entire databases or tablespaces, so it is
|
||||||
|
necessary to do that manually if the role owns any databases or
|
||||||
|
tablespaces that have not been transferred to new owners.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -456,7 +462,6 @@ ALTER TABLE bobs_table OWNER TO alice;
|
|||||||
<para>
|
<para>
|
||||||
In short then, the most general recipe for removing a role that has been
|
In short then, the most general recipe for removing a role that has been
|
||||||
used to own objects is:
|
used to own objects is:
|
||||||
|
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
REASSIGN OWNED BY doomed_role TO successor_role;
|
REASSIGN OWNED BY doomed_role TO successor_role;
|
||||||
@ -465,6 +470,12 @@ DROP OWNED BY doomed_role;
|
|||||||
DROP ROLE doomed_role;
|
DROP ROLE doomed_role;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
When not all owned objects are to be transferred to the same successor
|
||||||
|
owner, it's best to handle the exceptions manually and then perform
|
||||||
|
the above steps to mop up.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If <command>DROP ROLE</> is attempted while dependent objects still
|
If <command>DROP ROLE</> is attempted while dependent objects still
|
||||||
remain, it will issue messages identifying which objects need to be
|
remain, it will issue messages identifying which objects need to be
|
||||||
|
Loading…
Reference in New Issue
Block a user