Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/role-removal.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Dropping Roles</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Database Roles"
HREF="user-manag.html"><LINK
REL="PREVIOUS"
TITLE="Role Membership"
HREF="role-membership.html"><LINK
REL="NEXT"
TITLE="Function and Trigger Security"
HREF="perm-functions.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Role Membership"
HREF="role-membership.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="user-manag.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 20. Database Roles</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Function and Trigger Security"
HREF="perm-functions.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="ROLE-REMOVAL"
>20.4. Dropping Roles</A
></H1
><P
> Because roles can own database objects and can hold privileges
to access other objects, dropping a role is often not just a matter of a
quick <A
HREF="sql-droprole.html"
>DROP ROLE</A
>. Any objects owned by the role must
first be dropped or reassigned to other owners; and any permissions
granted to the role must be revoked.
</P
><P
> Ownership of objects can be transferred one at a time
using <TT
CLASS="COMMAND"
>ALTER</TT
> commands, for example:
</P><PRE
CLASS="PROGRAMLISTING"
>ALTER TABLE bobs_table OWNER TO alice;</PRE
><P>
Alternatively, the <A
HREF="sql-reassign-owned.html"
>REASSIGN OWNED</A
> command can be
used to reassign ownership of all objects owned by the role-to-be-dropped
to a single other role. Because <TT
CLASS="COMMAND"
>REASSIGN OWNED</TT
> cannot access
objects in other databases, it is necessary to run it in each database
that contains objects owned by the role. (Note that the first
such <TT
CLASS="COMMAND"
>REASSIGN OWNED</TT
> will change the ownership of any
shared-across-databases objects, that is databases or tablespaces, that
are owned by the role-to-be-dropped.)
</P
><P
> Once any valuable objects have been transferred to new owners, any
remaining objects owned by the role-to-be-dropped can be dropped with
the <A
HREF="sql-drop-owned.html"
>DROP OWNED</A
> command. Again, this command cannot
access objects in other databases, so it is necessary to run it in each
database that contains objects owned by the role. Also, <TT
CLASS="COMMAND"
>DROP
OWNED</TT
> 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.
</P
><P
> <TT
CLASS="COMMAND"
>DROP OWNED</TT
> also takes care of removing any privileges granted
to the target role for objects that do not belong to it.
Because <TT
CLASS="COMMAND"
>REASSIGN OWNED</TT
> does not touch such objects, it's
typically necessary to run both <TT
CLASS="COMMAND"
>REASSIGN OWNED</TT
>
and <TT
CLASS="COMMAND"
>DROP OWNED</TT
> (in that order!) to fully remove the
dependencies of a role to be dropped.
</P
><P
> In short then, the most general recipe for removing a role that has been
used to own objects is:
</P
><PRE
CLASS="PROGRAMLISTING"
>REASSIGN OWNED BY doomed_role TO successor_role;
DROP OWNED BY doomed_role;
-- repeat the above commands in each database of the cluster
DROP ROLE doomed_role;</PRE
><P
> 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.
</P
><P
> If <TT
CLASS="COMMAND"
>DROP ROLE</TT
> is attempted while dependent objects still
remain, it will issue messages identifying which objects need to be
reassigned or dropped.
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="role-membership.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="perm-functions.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Role Membership</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="user-manag.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Function and Trigger Security</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
Mini Shell