ALTER TABLE table_name OWNER TO new_owner;
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.
+ both the current owner of the object (or inherit the privileges of the
+ owning role) and able to SET ROLE to the new owning role.
You must own the aggregate function to use ALTER AGGREGATE.
To change the schema of an aggregate function, you must also have
CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the aggregate function's schema. (These restrictions enforce that altering
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the aggregate function's schema.
+ (These restrictions enforce that altering
the owner doesn't do anything you couldn't do by dropping and recreating
the aggregate function. However, a superuser can alter ownership of any
aggregate function anyway.)
You must own the collation to use ALTER COLLATION.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the collation's schema. (These restrictions enforce that altering the
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the collation's schema.
+ (These restrictions enforce that altering the
owner doesn't do anything you couldn't do by dropping and recreating the
collation. However, a superuser can alter ownership of any collation
anyway.)
You must own the conversion to use ALTER CONVERSION.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the conversion's schema. (These restrictions enforce that altering the
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the conversion's schema.
+ (These restrictions enforce that altering the
owner doesn't do anything you couldn't do by dropping and recreating the
conversion. However, a superuser can alter ownership of any conversion
anyway.)
The third form changes the owner of the database.
- To alter the owner, you must own the database and also be a direct or
- indirect member of the new owning role, and you must have the
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and you must have the
CREATEDB privilege.
(Note that superusers have all these privileges automatically.)
You must own the domain to use ALTER DOMAIN.
To change the schema of a domain, you must also have
CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the domain's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE privilege
+ on the domain's schema. (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the domain.
However, a superuser can alter ownership of any domain anyway.)
You must own the table to use ALTER FOREIGN TABLE.
To change the schema of a foreign table, you must also have
CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the table's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE privilege
+ on the table's schema. (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the table.
However, a superuser can alter ownership of any table anyway.)
To add a column or alter a column type, you must also
You must own the function to use ALTER FUNCTION.
To change a function's schema, you must also have CREATE
- privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
+ privilege on the new schema. To alter the owner, you must be able to
+ SET ROLE to the new owning role, and that role must
+ have CREATE privilege on
the function's schema. (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the function.
However, a superuser can alter ownership of any function anyway.)
You must own the large object to use ALTER LARGE OBJECT.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role. (However, a superuser can alter any large object anyway.)
+ To alter the owner, you must also be able to SET ROLE to
+ the new owning role.
+ (However, a superuser can alter any large object anyway.)
Currently, the only functionality is to assign a new owner, so both
restrictions always apply.
You must own the materialized view to use ALTER MATERIALIZED
VIEW. To change a materialized view's schema, you must also have
CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the materialized view's schema. (These restrictions enforce that altering
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the materialized view's schema.
+ (These restrictions enforce that altering
the owner doesn't do anything you couldn't do by dropping and recreating the
materialized view. However, a superuser can alter ownership of any view
anyway.)
You must own the operator class to use ALTER OPERATOR CLASS.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the operator class's schema. (These restrictions enforce that altering the
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the operator class's schema.
+ (These restrictions enforce that altering the
owner doesn't do anything you couldn't do by dropping and recreating the
operator class. However, a superuser can alter ownership of any operator
class anyway.)
You must own the operator to use ALTER OPERATOR.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the operator's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the operator's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the operator.
However, a superuser can alter ownership of any operator anyway.)
You must own the procedure to use ALTER PROCEDURE.
To change a procedure's schema, you must also have CREATE
privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the procedure's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the procedure's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the procedure.
However, a superuser can alter ownership of any procedure anyway.)
Adding a table to a publication additionally requires owning that table.
The ADD TABLES IN SCHEMA and
SET TABLES IN SCHEMA to a publication requires the
- invoking user to be a superuser. To alter the owner, you must also be a
- direct or indirect member of the new owning role. The new owner must have
- CREATE privilege on the database. Also, the new owner
- of a FOR ALL TABLES or FOR TABLES IN SCHEMA
+ invoking user to be a superuser.
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the database.
+ Also, the new owner of a FOR ALL TABLES or
+ FOR TABLES IN SCHEMA
publication must be a superuser. However, a superuser can
change the ownership of a publication regardless of these restrictions.
You must own the schema to use ALTER SCHEMA.
To rename a schema you must also have the
CREATE privilege for the database.
- To alter the owner, you must also be a direct or
- indirect member of the new owning role, and you must have the
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have the
CREATE privilege for the database.
(Note that superusers have all these privileges automatically.)
You must own the sequence to use ALTER SEQUENCE.
To change a sequence's schema, you must also have CREATE
privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the sequence's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the sequence's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the sequence.
However, a superuser can alter ownership of any sequence anyway.)
To alter the server you must be the owner of the server.
- Additionally to alter the owner, you must own the server and also
- be a direct or indirect member of the new owning role, and you must
+ Additionally to alter the owner, you must be able to
+ SET ROLE to the new owning role, and you must
have USAGE privilege on the server's foreign-data
wrapper. (Note that superusers satisfy all these criteria
automatically.)
You must own the statistics object to use ALTER STATISTICS.
To change a statistics object's schema, you must also
have CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the statistics object's schema. (These restrictions enforce that altering
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the statistics object's schema.
+ (These restrictions enforce that altering
the owner doesn't do anything you couldn't do by dropping and recreating
the statistics object. However, a superuser can alter ownership of any
statistics object anyway.)
You must own the subscription to use ALTER SUBSCRIPTION.
- To alter the owner, you must also be a direct or indirect member of the
- new owning role. The new owner has to be a superuser.
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role. The new owner has to be a superuser.
(Currently, all subscription owners must be superusers, so the owner checks
will be bypassed in practice. But this might change in the future.)
To add the table as a new child of a parent table, you must own the parent
table as well. Also, to attach a table as a new partition of the table,
you must own the table being attached.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the table's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the table's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the table.
However, a superuser can alter ownership of any table anyway.)
To add a column or alter a column type or use the OF
You must own the tablespace to change the definition of a tablespace.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role.
+ To alter the owner, you must also be able to SET ROLE
+ to the new owning role.
(Note that superusers have these privileges automatically.)
You must own the type to use ALTER TYPE.
To change the schema of a type, you must also have
CREATE privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the type's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the type's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the type.
However, a superuser can alter ownership of any type anyway.)
To add an attribute or alter an attribute type, you must also
You must own the view to use ALTER VIEW.
To change a view's schema, you must also have CREATE
privilege on the new schema.
- To alter the owner, you must also be a direct or indirect member of the new
- owning role, and that role must have CREATE privilege on
- the view's schema. (These restrictions enforce that altering the owner
+ To alter the owner, you must be able to SET ROLE to the
+ new owning role, and that role must have CREATE
+ privilege on the view's schema.
+ (These restrictions enforce that altering the owner
doesn't do anything you couldn't do by dropping and recreating the view.
However, a superuser can alter ownership of any view anyway.)
The role name of the user who will own the new database,
or DEFAULT to use the default (namely, the
user executing the command). To create a database owned by another
- role, you must be a direct or indirect member of that role,
- or be a superuser.
+ role, you must must be able to SET ROLE to that
+ role.
The role name of the user who will own the new schema. If omitted,
defaults to the user executing the command. To create a schema
- owned by another role, you must be a direct or indirect member of
- that role, or be a superuser.
+ owned by another role, you must must be able to
+ SET ROLE to that role.
This option defaults to TRUE.
+ To create an object owned by another role or give ownership of an existing
+ object to another role, you must have the ability to SET
+ ROLE to that role; otherwise, commands such as ALTER
+ ... OWNER TO or CREATE DATABASE ... OWNER
+ will fail. However, a user who inherits the privileges of a role but does
+ not have the ability to SET ROLE to that role may be
+ able to obtain full access to the role by manipulating existing objects
+ owned by that role (e.g. they could redefine an existing function to act
+ as a Trojan horse). Therefore, if a role's privileges are to be inherited
+ but should not be accessible via SET ROLE, it should not
+ own any SQL objects.
+
+
If GRANTED BY is specified, the grant is recorded as
having been done by the specified role. A user can only attribute a grant