Aspectos del DCL en Postgresql

Chapter 18. Database Roles and Privileges

PostgreSQL manages database access permissions using the concept of roles. A role can be thought
of as either a database user, or a group of database users, depending on how the role is set up. Roles
can own database objects (for example, tables and can assign pri!ileges on those objects to other
roles to control who has access to which objects. "urthermore, it is possible to grant membership in
a role to another role, thus allowing the member role use of pri!ileges assigned to the role it is a
member of.
#he concept of roles subsumes the concepts of $users% and $groups%. &n PostgreSQL !ersions
before '.(, users and groups were distinct )inds of entities, but now there are onl* roles. An* role
can act as a user, a group, or both.
#his chapter describes how to create and manage roles and introduces the pri!ilege s*stem. +ore
information about the !arious t*pes of database objects and the effects of pri!ileges can be found in
,hapter -.
18.1. Database Roles
.atabase roles are conceptuall* completel* separate from operating s*stem users. &n practice it
might be con!enient to maintain a correspondence, but this is not re/uired. .atabase roles are
global across a database cluster installation (and not per indi!idual database. #o create a role use
the ,R0A#0 R1L0 SQL command2
,R0A#0 R1L0 name3
name follows the rules for SQL identifiers2 either unadorned without special characters, or double4
/uoted. (&n practice, *ou will usuall* want to add additional options, such as L15&6, to the
command. +ore details appear below. #o remo!e an existing role, use the analogous .R1P R1L0
command2
.R1P R1L0 name3
"or con!enience, the programs createuser and dropuser are pro!ided as wrappers around these SQL
commands that can be called from the shell command line2
createuser name
dropuser name
#o determine the set of existing roles, examine the pg7roles s*stem catalog, for example
SELECT rolname R!" pg#roles$
#he ps/l program8s %d& meta4command is also &se'&l 'or listing the e(isting roles.
&n order to bootstrap the database s*stem, a freshl* initiali9ed s*stem alwa*s contains one
predefined role.
#his role is alwa*s a $s&per&ser%, and b* default (unless altered when running initdb it will ha!e
the same name as the operating s*stem user that initiali9ed the database cluster. ,ustomaril*, this
role will be named postgres. &n order to create more roles *ou first ha!e to connect as this initial
role.
0!er* connection to the database ser!er is made in the name of some particular role, and this role
determines the initial access pri!ileges for commands issued on that connection. #he role name to
use for a particular database connection is indicated b* the client that is initiating the connection
re/uest in an application4specific fashion. "or example, the ps/l program uses the 4: command line
option to indicate the role to connect as. +an* applications assume the name of the current
operating s*stem user b* default (including createuser and ps/l. #herefore it is often con!enient to
maintain a naming correspondence between roles and operating s*stem users.
#he set of database roles a gi!en client connection ma* connect as is determined b* the client
authentication setup, as explained in ,hapter ;<. (#hus, a client is not necessaril* limited to connect
as the role with the same name as its operating s*stem user, just as a person8s login name need not
match her real name.
Since the role identit* determines the set of pri!ileges a!ailable to a connected client, it is important
to carefull* configure this when setting up a multiuser en!ironment.
18.). Role Attrib&tes
A database role ma* ha!e a number of attributes that define its pri!ileges and interact with the client
authentication s*stem. login pri!ilege
1nl* roles that ha!e the L15&6 attribute can be used as the initial role name for a database
connection.
A role with the L15&6 attribute can be considered the same thing as a $database user%. #o create a
role with login pri!ilege, use either
,R0A#0 R1L0 name L15&63
,R0A#0 :S0R name3
(,R0A#0 :S0R is e/ui!alent to ,R0A#0 R1L0 except that ,R0A#0 :S0R assumes L15&6 b*
default, while ,R0A#0 R1L0 does not. superuser status
A database superuser b*passes all permission chec)s. #his is a dangerous pri!ilege and should not
be used carelessl*3 it is best to do most of *our wor) as a role that is not a superuser. #o create a
new database superuser, use ,R0A#0 R1L0 name S:P0R:S0R. =ou must do this as a role that is
alread* a superuser.
database creation
A role must be explicitl* gi!en permission to create databases (except for superusers, since those
b*pass all permission chec)s. #o create such a role, use ,R0A#0 R1L0 name ,R0A#0.>.
role creation
A role must be explicitl* gi!en permission to create more roles (except for superusers, since those
b*pass all permission chec)s. #o create such a role, use ,R0A#0 R1L0 name ,R0A#0R1L0. A
role with ,R0A#0R1L0 pri!ilege can alter and drop other roles, too, as well as grant or re!o)e
membership in them. ?owe!er, to create, alter, drop, or change membership of a superuser role,
superuser status is re/uired3 ,R0A#0R1L0 is not sufficient for that.
pass*ord
A password is onl* significant if the client authentication method re/uires the user to suppl* a
password when connecting to the database. #he password, md-, and cr*pt authentication methods
ma)e use of passwords. .atabase passwords are separate from operating s*stem passwords. Specif*
a password upon role creation with ,R0A#0 R1L0 name PASS@1R. 8string 8.
A role8s attributes can be modified after creation with AL#0R R1L0. See the reference pages for
the ,R0A#0 R1L0 and AL#0R R1L0 commands for details.
#ip2 &t is good practice to create a role that has the ,R0A#0.> and ,R0A#0R1L0 pri!ileges, but
is not a superuser, and then use this role for all routine management of databases and roles. #his
approach a!oids the dangers of operating as a superuser for tas)s that do not reall* re/uire it.
A role can also ha!e role4specific defaults for man* of the run4time configuration settings described
in ,hapter (A. "or example, if for some reason *ou want to disable index scans (hint2 not a good
idea an*time *ou connect, *ou can use AL#0R R1L0 m*name S0# enable7indexscan #1 off3
#his will sa!e the setting (but not set it immediatel*. &n subse/uent connections b* this role it will
appear as though S0# enable7indexscan #1 off3 had been executed just before the session started.
=ou can still alter this setting during the session3 it will onl* be the default. #o remo!e a role4
specific default setting, use AL#0R R1L0 rolename R0S0# !arname3. 6ote that role4specific
defaults attached to roles without L15&6 pri!ilege are fairl* useless, since the* will ne!er be
in!o)ed.
18.+. Privileges
@hen an object is created, it is assigned an owner. #he owner is normall* the role that executed the
creation statement. "or most )inds of objects, the initial state is that onl* the owner (or a superuser
can do an*thing with the object. #o allow other roles to use it, pri!ileges must be granted. #here are
se!eral different )inds of pri!ilege2 S0L0,#, &6S0R#, :P.A#0, .0L0#0, R:L0,
R0"0R06,0S, #R&550R, ,R0A#0, #0+P1RAR=, 0B0,:#0, and :SA50. "or more
information on the different t*pes of pri!ileges supported b* PostgreSQL, see the 5RA6#
reference page.
#o assign pri!ileges, the 5RA6# command is used. So, if joe is an existing role, and accounts is an
existing table, the pri!ilege to update the table can be granted with
5RA6# :P.A#0 16 accounts #1 joe3
#he special name P,-L.C can be used to grant a pri!ilege to e!er* role on the s*stem. @riting
ALL in place of a specific pri!ilege specifies that all pri!ileges that appl* to the object will be
granted.

#o re!o)e a pri!ilege, use the fittingl* named R0C1D0 command2
R0C1D0 ALL 16 accounts "R1+ P:>L&,3
#he special pri!ileges of an object8s owner (i.e., the right to modif* or destro* the object are
alwa*s implicit in being the owner, and cannot be granted or re!o)ed. >ut the owner can choose to
re!o)e his own ordinar* pri!ileges, for example to ma)e a table read4onl* for himself as well as
others.
An object can be assigned to a new owner with an AL#0R command of the appropriate )ind for the
object.
Superusers can alwa*s do this3 ordinar* roles can onl* do it if the* are both the current owner of the
object (or a member of the owning role and a member of the new owning role.
18./. Role "embership
&t is fre/uentl* con!enient to group users together to ease management of pri!ileges2 that wa*,
pri!ileges can be granted to, or re!o)ed from, a group as a whole. &n PostgreSQL this is done b*
creating a role that represents the group, and then granting membership in the group role to
indi!idual user roles.
#o set up a group role, first create the role2
,R0A#0 R1L0 name3
#*picall* a role being used as a group would not ha!e the L15&6 attribute, though *ou can set it if
*ou wish.
1nce the group role exists, *ou can add and remo!e members using the 5RA6# and R0C1D0
commands2
0RA1T gro&p#role T! role12 ... $
RE3!4E gro&p#role R!" role12 ... $
=ou can grant membership to other group roles, too (since there isn8t reall* an* distinction between
group roles and non4group roles. #he database will not let *ou set up circular membership loops.
Also, it is not permitted to grant membership in a role to P,-L.C.
The members o' a role can &se the privileges o' the gro&p role in t*o *a5s. irst2 ever5
member o' a gro&p can e(plicitl5 do SET R!LE to temporaril5 6become7 the gro&p role. .n
this state2 the database session has access to the privileges o' the gro&p role rather than the
original login role2 and an5 database ob8ects created are considered o*ned b5 the gro&p role
not the login role. Second2 member roles that have the .19ER.T attrib&te a&tomaticall5 have
&se o' privileges o' roles the5 are members o'. As an example, suppose we ha!e done
CREATE R!LE 8oe L!0.1 .19ER.T$
CREATE R!LE admin 1!.19ER.T$
CREATE R!LE *heel 1!.19ER.T$
0RA1T admin T! 8oe$
0RA1T *heel T! admin$
&mmediatel* after connecting as role joe, a database session will ha!e use of pri!ileges granted
directl5 to joe pl&s an* pri!ileges granted to admin, because joe $inherits% admin:s privileges.
?owe!er, pri!ileges granted to wheel are not a!ailable, because e!en though joe is indirectl* a
member of wheel, the membership is !ia admin which has the 61&6?0R&# attribute. After
SET R!LE admin$
the session would ha!e use of onl* those pri!ileges granted to admin, and not those granted to joe.
After
SET R!LE *heel$
the session would ha!e use of onl* those pri!ileges granted to wheel, and not those granted to either
joe or admin. #he original privilege state can be restored *ith an5 o'
SET R!LE 8oe$
SET R!LE 1!1E$
RESET R!LE$
1ote; The SET R!LE command al*a5s allo*s selecting an5 role that the original login role is
directl5 or indirectl5 a member o'. Th&s2 in the above e(ample2 it is not necessar5 to become
admin be'ore becoming *heel.
6ote2 &n the SQL standard, there is a clear distinction between users and roles, and users do not
automaticall* inherit pri!ileges while roles do. #his beha!ior can be obtained in PostgreSQL b*
gi!ing roles being used as SQL roles the &6?0R&# attribute, while gi!ing roles being used as SQL
users the 61&6?0R&# attribute. ?owe!er, PostgreSQL defaults to gi!ing all roles the &6?0R&#
attribute, for bac)wards compatibilit* with pre4'.( releases in which users alwa*s had use of
permissions granted to groups the* were members of.
#he role attributes L15&6, S:P0R:S0R, ,R0A#0.>, and ,R0A#0R1L0 can be thought of as
special pri!ileges, but the* are ne!er inherited as ordinar* pri!ileges on database objects are. =ou
must actuall* S0# R1L0 to a specific role ha!ing one of these attributes in order to ma)e use of the
attribute. ,ontinuing the abo!e example, we might well choose to grant ,R0A#0.> and
,R0A#0R1L0 to the admin role. #hen a session connecting as role joe would not ha!e these
pri!ileges immediatel*, onl* after doing
S0# R1L0 admin.
#o destro* a group role, use .R1P R1L02
.R1P R1L0 name3
An* memberships in the group role are automaticall* re!o)ed (but the member roles are not
otherwise affected. 6ote howe!er that an* objects owned b* the group role must first be dropped
or reassigned to other owners3 and an* permissions granted to the group role must be re!o)ed.
CREATE 3.E<
6ame
,R0A#0 C&0@ E define a new !iew
S*nopsis
CREATE = !R REPLACE > = TE"P ? TE"P!RAR@ > 3.E<
name = A col&mn#name =2 ...> B >
AS q&er5
.escription
,R0A#0 C&0@ defines a !iew of a /uer*. #he !iew is not ph*sicall* materiali9ed. &nstead, the
/uer* is run e!er* time the !iew is referenced in a /uer*.
,R0A#0 1R R0PLA,0 C&0@ is similar, but if a !iew of the same name alread* exists, it is
replaced. =ou can onl* replace a !iew with a new /uer* that generates the identical set of columns
(i.e., same column names and data t*pes.
&f a schema name is gi!en (for example, ,R0A#0 C&0@ m*schema.m*!iew ... then the !iew is
created in the specified schema. 1therwise it is created in the current schema. #emporar* !iews
exist in a special schema, so a schema name ma* not be gi!en when creating a temporar* !iew. #he
name of the !iew must be distinct from the name of an* other !iew, table, se/uence, or index in the
same schema.
Parameters
#0+P1RAR= or #0+P
&f specified, the !iew is created as a temporar* !iew. #emporar* !iews are automaticall* dropped at
the end of the current session. 0xisting permanent relations with the same name are not !isible to
the current session while the temporar* !iew exists, unless the* are referenced with schema4
/ualified names.
&f an* of the tables referenced b* the !iew are temporar*, the !iew is created as a temporar* !iew
(whether #0+P1RAR= is specified or not.
name
#he name (optionall* schema4/ualified of a !iew to be created.
column7name
An optional list of names to be used for columns of the !iew. &f not gi!en, the column names are
deduced from the /uer*. /uer*
A /uer* (that is, a S0L0,# statement which will pro!ide the columns and rows of the !iew.
Referto S0L0,# for more information about !alid /ueries.
6otes
,urrentl*, !iews are read onl*2 the s*stem will not allow an insert, update, or delete on a !iew. =ou
can get the effect of an updatable !iew b* creating rules that rewrite inserts, etc. on the !iew into
appropriate actions on other tables. "or more information see ,R0A#0 R:L0.
:se the .R1P C&0@ statement to drop !iews.
>e careful that the names and t*pes of the !iew8s columns will be assigned the wa* *ou want. "or
example,
,R0A#0 C&0@ !ista AS S0L0,# 8?ello @orld83
is bad form in two wa*s2 the column name defaults to FcolumnF, and the column data t*pe defaults
to un)nown. &f *ou want a string literal in a !iew8s result, use something li)e
,R0A#0 C&0@ !ista AS S0L0,# text 8?ello @orld8 AS hello3
Access to tables referenced in the !iew is determined b* permissions of the !iew owner. ?owe!er,
functions called in the !iew are treated the same as if the* had been called directl* from the /uer*
using the !iew. #herefore the user of a !iew must ha!e permissions to call all functions used b* the
!iew.
E(amples
,reate a !iew consisting of all comed* films2
,R0A#0 C&0@ comedies AS
S0L0,# G
"R1+ films
@?0R0 )ind H 8,omed*83
,ompatibilit*
#he SQL standard specifies some additional capabilities for the ,R0A#0 C&0@ statement2
,R0A#0 C&0@ name I ( column7name I, ...J J
AS /uer*
I @&#? I ,AS,A.0. K L1,AL J ,?0,D 1P#&16 J
#he optional clauses for the full SQL command are2
,?0,D 1P#&16
#his option has to do with updatable !iews. All &6S0R# and :P.A#0 commands on the !iew will
be chec)ed to ensure data satisf* the !iew4defining condition (that is, the new data would be !isible
through the !iew. &f the* do not, the update will be rejected.
L1,AL
,hec) for integrit* on this !iew.
,AS,A.0.
,hec) for integrit* on this !iew and on an* dependent !iew. ,AS,A.0. is assumed if neither
,AS,A.0. nor L1,AL is specified.
,R0A#0 1R R0PLA,0 C&0@ is a PostgreSQL language extension. So is the concept of a
temporar* !iew.
See Also
.R1P C&0@
CREATE R!LE
6ame
,R0A#0 R1L0 E define a new database role
S*nopsis
CREATE R!LE name = = <.T9 > option = ... > >
where option can be2
K K
S,PER,SER ? 1!S,PER,SER
CREATED- ? 1!CREATED-
CREATER!LE ? 1!CREATER!LE
CREATE,SER ? 1!CREATE,SER
.19ER.T ? 1!.19ER.T
L!0.1 ? 1!L!0.1
C!11ECT.!1 L.".T connlimit
= E1CR@PTED ? ,1E1CR@PTED > PASS<!RD :pass*ord :
3AL.D ,1T.L :timestamp:
.1 R!LE rolename =2 ...>
.1 0R!,P rolename =2 ...>
R!LE rolename =2 ...>
AD".1 rolename =2 ...>
,SER rolename =2 ...>
S@S.D &id
.escription
,R0A#0 R1L0 adds a new role to a PostgreSQL database cluster. A role is an entit* that can own
database objects and ha!e database pri!ileges3 a role can be considered a $user%, a $group%, or both
depending on how it is used. Refer to ,hapter (' and ,hapter ;< for information about managing
users and authentication. =ou must ha!e ,R0A#0R1L0 pri!ilege or be a database superuser to use
this command.
6ote that roles are defined at the database cluster le!el, and so are !alid in all databases in the
cluster.
Parameters
name
#he name of the new role.
S:P0R:S0R
61S:P0R:S0R
#hese clauses determine whether the new role is a $superuser%, who can o!erride all access
restrictions within the database. Superuser status is dangerous and should be used onl* when reall*
needed.
=ou must *ourself be a superuser to create a new superuser. &f not specified, 61S:P0R:S0R is
the default.
,R0A#0.>
61,R0A#0.>
#hese clauses define a role8s abilit* to create databases. &f ,R0A#0.> is specified, the role being
defined will be allowed to create new databases. Specif*ing 61,R0A#0.> will den* a role the
abilit* to create databases. &f not specified, 61,R0A#0.> is the default.
,R0A#0R1L0
61,R0A#0R1L0
#hese clauses determine whether a role will be permitted to create new roles (that is, execute
,R0A#0 R1L0. A role with ,R0A#0R1L0 pri!ilege can also alter and drop other roles. &f not
specified, 61,R0A#0R1L0 is the default.
,R0A#0:S0R
61,R0A#0:S0R
#hese clauses are an obsolete, but still accepted, spelling of S:P0R:S0R and 61S:P0R:S0R.
6ote that the* are not e/ui!alent to ,R0A#0R1L0 as one might nai!el* expectL
&6?0R&#
61&6?0R&#
#hese clauses determine whether a role $inherits% the pri!ileges of roles it is a member of. A role
with the &6?0R&# attribute can automaticall* use whate!er database pri!ileges ha!e been granted
to all roles it is directl* or indirectl* a member of. @ithout &6?0R&#, membership in another role
onl* grants the abilit* to S0# R1L0 to that other role3 the pri!ileges of the other role are onl*
a!ailable after ha!ing done so. &f not specified, &6?0R&# is the default.
L15&6
61L15&6
#hese clauses determine whether a role is allowed to log in3 that is, whether the role can be gi!en
as the initial session authori9ation name during client connection. A role ha!ing the L15&6
attribute can be thought of as a user. Roles without this attribute are useful for managing database
pri!ileges, but are not users in the usual sense of the word. &f not specified, 61L15&6 is the
default, except when ,R0A#0 R1L0 is in!o)ed through its alternate spelling ,R0A#0 :S0R.
,1660,#&16 L&+&# connlimit
&f role can log in, this specifies how man* concurrent connections the role can ma)e. 4( (the
default means no limit.
PASS@1R. password
Sets the role8s password. (A password is onl* of use for roles ha!ing the L15&6 attribute, but *ou
can nonetheless define one for roles without it. &f *ou do not plan to use password authentication
*ou can omit this option.
06,R=P#0.
:606,R=P#0.
#hese )e* words control whether the password is stored encr*pted in the s*stem catalogs. (&f
neither is specified, the default beha!ior is determined b* the configuration parameter
password7encr*ption.
&f the presented password string is alread* in +.-4encr*pted format, then it is stored encr*pted as
is, regardless of whether 06,R=P#0. or :606,R=P#0. is specified (since the s*stem cannot
decr*pt the specified encr*pted password string. #his allows reloading of encr*pted passwords
during dumpMrestore.
6ote that older clients ma* lac) support for the +.- authentication mechanism that is needed to
wor) with passwords that are stored encr*pted.
CAL&. :6#&L 8timestamp8
#he CAL&. :6#&L clause sets a date and time after which the role8s password is no longer !alid. &f
this clause is omitted the password will be !alid for all time.
&6 R1L0 rolename
#he &6 R1L0 clause lists one or more existing roles to which the new role will be immediatel*
added as a new member. (6ote that there is no option to add the new role as an administrator3 use a
separate 5RA6# command to do that.
&6 5R1:P rolename
&6 5R1:P is an obsolete spelling of &6 R1L0.
R1L0 rolename
#he R1L0 clause lists one or more existing roles which are automaticall* added as members of the
new role. (#his in effect ma)es the new role a $group%.
A.+&6 rolename
#he A.+&6 clause is li)e R1L0, but the named roles are added to the new role @&#? A.+&6
1P#&16, gi!ing them the right to grant membership in this role to others.
:S0R rolename
#he :S0R clause is an obsolete spelling of the R1L0 clause.
S=S&. uid
#he S=S&. clause is ignored, but is accepted for bac)wards compatibilit*.
6otes :se AL#0R R1L0 to change the attributes of a role, and .R1P R1L0 to remo!e a role. All
the attributes specified b* ,R0A#0 R1L0 can be modified b* later AL#0R R1L0 commands.
#he preferred wa* to add and remo!e members of roles that are being used as groups is to use
5RA6# and R0C1D0.
#he CAL&. :6#&L clause defines an expiration time for a password onl*, not for the role per se. &n
particular, the expiration time is not enforced when logging in using a non4password4based
authentication method.
#he &6?0R&# attribute go!erns inheritance of grantable pri!ileges (that is, access pri!ileges for
database objects and role memberships. &t does not appl* to the special role attributes set b*
,R0A#0 R1L0 and AL#0R R1L0. "or example, being a member of a role with ,R0A#0.>
pri!ilege does not immediatel* grant the abilit* to create databases, e!en if &6?0R&# is set3 it
would be necessar* to become that role !ia S0# R1L0 before creating a database.
#he &6?0R&# attribute is the default for reasons of bac)wards compatibilit*2 in prior releases of
PostgreSQL, users alwa*s had access to all pri!ileges of groups the* were members of. ?owe!er,
61&6?0R&# pro!ides a closer match to the semantics specified in the SQL standard.
>e careful with the ,R0A#0R1L0 pri!ilege. #here is no concept of inheritance for the pri!ileges
of a ,R0A#0R1L04role. #hat means that e!en if a role does not ha!e a certain pri!ilege but is
allowed to create other roles, it can easil* create another role with different pri!ileges than its own
(except for creating roles with superuser pri!ileges. "or example, if the role $user% has the
,R0A#0R1L0 pri!ilege but not the ,R0A#0.> pri!ilege, nonetheless it can create a new role
with the ,R0A#0.> pri!ilege. #herefore, regard roles that ha!e the ,R0A#0R1L0 pri!ilege as
almost4superuser4roles.
PostgreSQL includes a program createuser that has the same functionalit* as ,R0A#0 R1L0 (in
fact, it calls this command but can be run from the command shell.
#he ,1660,#&16 L&+&# option is onl* enforced approximatel*3 if two new sessions start at
about the same time when just one connection $slot% remains for the role, it is possible that both
will fail. Also, the limit is ne!er enforced for superusers.
E(amples
,reate a role that can log in, but don8t gi!e it a password2
CREATE R!LE 8onathan L!0.1$
,reate a role with a password2
CREATE ,SER davide <.T9 PASS<!RD :8*8sC/:$
(,R0A#0 :S0R is the same as ,R0A#0 R1L0 except that it implies L15&6.
,reate a role with a password that is !alid until the end of ;<<N. After one second has tic)ed in
;<<-, the password is no longer !alid.
CREATE R!LE miriam <.T9 L!0.1 PASS<!RD :8*8sC/: 3AL.D ,1T.L :)CCDEC1EC1:$
,reate a role that can create databases and manage roles2
CREATE R!LE admin <.T9 CREATED- CREATER!LE$
,ompatibilit*
#he ,R0A#0 R1L0 statement is in the SQL standard, but the standard onl* re/uires the s*ntax
,R0A#0 R1L0 name I @&#? A.+&6 rolename J
+ultiple initial administrators, and all the other options of ,R0A#0 R1L0, are PostgreSQL
extensions.
#he SQL standard defines the concepts of users and roles, but it regards them as distinct concepts
and lea!es all commands defining users to be specified b* each database implementation. &n
PostgreSQL we ha!e chosen to unif* users and roles into a single )ind of entit*. Roles therefore
ha!e man* more optional attributes than the* do in the standard.
#he beha!ior specified b* the SQL standard is most closel* approximated b* gi!ing users the
61&6?0R&# attribute, while roles are gi!en the &6?0R&# attribute.
See Also
S0# R1L0, AL#0R R1L0, .R1P R1L0, 5RA6#, R0C1D0, createuser
0RA1T
6ame
5RA6# E define access pri!ileges
S*nopsis
0RA1T F F SELECT ? .1SERT ? ,PDATE ? DELETE ? R,LE ? REERE1CES ? TR.00ER G
=2...> ? ALL = PR.3.LE0ES > G
!1 = TA-LE > tablename =2 ...>
T! F &sername ? 0R!,P gro&pname ? P,-L.C G =2 ...> = <.T9 0RA1T !PT.!1 >
0RA1T F F CREATE ? TE"P!RAR@ ? TE"P G =2...> ? ALL = PR.3.LE0ES > G
!1 DATA-ASE dbname =2 ...>
T! F &sername ? 0R!,P gro&pname ? P,-L.C G =2 ...> = <.T9 0RA1T !PT.!1 >
5RA6# O 0B0,:#0 K ALL I PR&C&L050S J P
16 ":6,#&16 funcname ( I I argmode J I argname J argt*pe I, ...J J I, ...J
#1 O username K 5R1:P groupname K P:>L&, P I, ...J I @&#? 5RA6# 1P#&16 J
5RA6# O :SA50 K ALL I PR&C&L050S J P
16 LA65:A50 langname I, ...J
#1 O username K 5R1:P groupname K P:>L&, P I, ...J I @&#? 5RA6# 1P#&16 J
5RA6# O O ,R0A#0 K :SA50 P I,...J K ALL I PR&C&L050S J P
16 S,?0+A schemaname I, ...J
#1 O username K 5R1:P groupname K P:>L&, P I, ...J I @&#? 5RA6# 1P#&16 J
5RA6# O ,R0A#0 K ALL I PR&C&L050S J P
16 #A>L0SPA,0 tablespacename I, ...J
#1 O username K 5R1:P groupname K P:>L&, P I, ...J I @&#? 5RA6# 1P#&16 J
0RA1T role =2 ...> T! &sername =2 ...> = <.T9 AD".1 !PT.!1 >
.escription
#he 5RA6# command has two basic !ariants2 one that grants pri!ileges on a database object
(table, !iew, se/uence, database, function, procedural language, schema, or tablespace, and one
that grants member4 ship in a role. #hese !ariants are similar in man* wa*s, but the* are different
enough to be described separatel*.
As of PostgreSQL '.(, the concepts of users and groups ha!e been unified into a single )ind of
entit* called a role. &t is therefore no longer necessar* to use the )e*word 5R1:P to identif*
whether a grantee is a user or a group. 5R1:P is still allowed in the command, but it is a noise
word.
0RA1T on Database !b8ects
#his !ariant of the 5RA6# command gi!es specific pri!ileges on a database object to one or more
roles.
#hese pri!ileges are added to those alread* granted, if an*.
#he )e* word P:>L&, indicates that the pri!ileges are to be granted to all roles, including those
that ma* be created later. P:>L&, ma* be thought of as an implicitl* defined group that alwa*s
includes all roles.
An* particular role will ha!e the sum of pri!ileges granted directl* to it, pri!ileges granted to an*
role it is presentl* a member of, and pri!ileges granted to P:>L&,.
&f @&#? 5RA6# 1P#&16 is specified, the recipient of the pri!ilege ma* in turn grant it to others.
@ithout a grant option, the recipient cannot do that. 5rant options cannot be granted to P:>L&,.
#here is no need to grant pri!ileges to the owner of an object (usuall* the user that created it, as the
owner has all pri!ileges b* default. (#he owner could, howe!er, choose to re!o)e some of his own
pri!ileges for safet*. #he right to drop an object, or to alter its definition in an* wa* is not
described b* a grantable pri!ilege3 it is inherent in the owner, and cannot be granted or re!o)ed.
#he owner implicitl* has all grant options for the object, too.
.epending on the t*pe of object, the initial default pri!ileges ma* include granting some pri!ileges
to P:>L&,. #he default is no public access for tables, schemas, and tablespaces3 #0+P table
creation pri!ilege for databases3 0B0,:#0 pri!ilege for functions3 and :SA50 pri!ilege for
languages. #he object owner ma* of course re!o)e these pri!ileges. ("or maximum securit*, issue
the R0C1D0 in the same transaction that creates the object3 then there is no window in which
another user ma* use the object.
#he possible pri!ileges are2
S0L0,#
Allows S0L0,# from an* column of the specified table, !iew, or se/uence. Also allows the use of
,1P= #1. "or se/uences, this pri!ilege also allows the use of the curr!al function.
&6S0R#
Allows &6S0R# of a new row into the specified table. Also allows ,1P= "R1+.
:P.A#0
Allows :P.A#0 of an* column of the specified table. S0L0,# ... "1R :P.A#0 and S0L0,# ...
"1R S?AR0 also re/uire this pri!ilege (besides the S0L0,# pri!ilege. "or se/uences, this
pri!ilege allows the use of the next!al and set!al functions.
.0L0#0
Allows .0L0#0 of a row from the specified table.
R:L0
Allows the creation of a rule on the tableM!iew. (See the ,R0A#0 R:L0 statement.
R0"0R06,0S
#o create a foreign )e* constraint, it is necessar* to ha!e this pri!ilege on both the referencing and
referenced tables.
#R&550R
Allows the creation of a trigger on the specified table. (See the ,R0A#0 #R&550R statement.
,R0A#0
"or databases, allows new schemas to be created within the database.
"or schemas, allows new objects to be created within the schema. #o rename an existing object, *ou
must own the object and ha!e this pri!ilege for the containing schema.
"or tablespaces, allows tables and indexes to be created within the tablespace, and allows databases
to be created that ha!e the tablespace as their default tablespace. (6ote that re!o)ing this pri!ilege
will not alter the placement of existing objects.
#0+P1RAR=
#0+P
Allows temporar* tables to be created while using the database.
0B0,:#0
Allows the use of the specified function and the use of an* operators that are implemented on top of
the function. #his is the onl* t*pe of pri!ilege that is applicable to functions. (#his s*ntax wor)s for
aggregate functions, as well.
:SA50
"or procedural languages, allows the use of the specified language for the creation of functions in
that language. #his is the onl* t*pe of pri!ilege that is applicable to procedural languages.
"or schemas, allows access to objects contained in the specified schema (assuming that the objects8
own pri!ilege re/uirements are also met. 0ssentiall* this allows the grantee to $loo) up% objects
within the schema.
ALL PR&C&L050S
5rant all of the a!ailable pri!ileges at once. #he PR&C&L050S )e* word is optional in PostgreSQL,
though it is re/uired b* strict SQL.
#he pri!ileges re/uired b* other commands are listed on the reference page of the respecti!e
command.
0RA1T on Roles
#his !ariant of the 5RA6# command grants membership in a role to one or more other roles.
+embership in a role is significant because it con!e*s the pri!ileges granted to a role to each of its
members.
&f @&#? A.+&6 1P#&16 is specified, the member ma* in turn grant membership in the role to
others, and re!o)e membership in the role as well. @ithout the admin option, ordinar* users cannot
do that. ?owe!er, database superusers can grant or re!o)e membership in an* role to an*one. Roles
ha!ing ,R0A#0R1L0 pri!ilege can grant or re!o)e membership in an* role that is not a superuser.
:nli)e the case with pri!ileges, membership in a role cannot be granted to P:>L&,. 6ote also that
this form of the command does not allow the noise word 5R1:P.
6otes
#he R0C1D0 command is used to re!o)e access pri!ileges.
@hen a non4owner of an object attempts to 5RA6# pri!ileges on the object, the command will fail
outright if the user has no pri!ileges whatsoe!er on the object. As long as some pri!ilege is
a!ailable, the command will proceed, but it will grant onl* those pri!ileges for which the user has
grant options. #he 5RA6# ALL PR&C&L050S forms will issue a warning message if no grant
options are held, while the other forms will issue a warning if grant options for an* of the pri!ileges
specificall* named in the command are not held.
(&n principle these statements appl* to the object owner as well, but since the owner is alwa*s
treated as holding all grant options, the cases can ne!er occur.
&t should be noted that database superusers can access all objects regardless of object pri!ilege
settings.
#his is comparable to the rights of root in a :nix s*stem. As with root, it8s unwise to operate as a
superuser except when absolutel* necessar*.
&f a superuser chooses to issue a 5RA6# or R0C1D0 command, the command is performed as
though it were issued b* the owner of the affected object. &n particular, pri!ileges granted !ia such a
command will appear to ha!e been granted b* the object owner. ("or role membership, the
membership appears to ha!e been granted b* the containing role itself.
5RA6# and R0C1D0 can also be done b* a role that is not the owner of the affected object, but is
a member of the role that owns the object, or is a member of a role that holds pri!ileges @&#?
5RA6# 1P#&16 on the object. &n this case the pri!ileges will be recorded as ha!ing been granted
b* the role that actuall* owns the object or holds the pri!ileges @&#? 5RA6# 1P#&16. "or
example, if table t( is owned b* role g(, of which role u( is a member, then u( can grant pri!ileges
on t( to u;, but those pri!ileges will appear to ha!e been granted directl* b* g(. An* other member
of role g( could re!o)e them later.
&f the role executing 5RA6# holds the re/uired pri!ileges indirectl* !ia more than one role
membership path, it is unspecified which containing role will be recorded as ha!ing done the grant.
&n such cases it is best practice to use S0# R1L0 to become the specific role *ou want to do the
5RA6# as. ,urrentl*, PostgreSQL does not support granting or re!o)ing pri!ileges for indi!idual
columns of a table.
1ne possible wor)around is to create a !iew ha!ing just the desired columns and then grant
pri!ileges to that !iew.
,se psql:s %H command to obtain in'ormation abo&t e(isting privileges2 'or e(ample;
IJ %H m5table
Access pri!ileges for database QlusitaniaQ
Schema K 6ame K #*pe K
Access pri!ileges
44444444R444444444R4444444R444444444444444444444444444444444444444444444444444444444444
public K m*table K table K OmiriamHarwdRxtMmiriam,HrMmiriam,Qgroup todosHarwMmiriamQP
(( row
#he entries shown b* S9 are interpreted thus2
Hxxxx 44 pri!ileges granted to P:>L&,
unameHxxxx 44 pri!ileges granted to a user
group gnameHxxxx 44 pri!ileges granted to a group
r S0L0,# (QreadQ
w :P.A#0 (QwriteQ
a &6S0R# (QappendQ
d .0L0#0
R R:L0
x R0"0R06,0S
arwdRxt
G
t #R&550R
B 0B0,:#0
: :SA50
, ,R0A#0
# #0+P1RAR=
ALL PR&C&L050S (for tables
grant option for preceding pri!ilege
M**** 44 user who granted this pri!ilege
#he abo!e example displa* would be seen b* user miriam after creating table m*table and doing
0RA1T SELECT !1 m5table T! P,-L.C$
0RA1T SELECT2 ,PDATE2 .1SERT !1 m5table T! 0R!,P todos$
&f the $Access pri!ileges% column is empt* for a gi!en object, it means the object has default
pri!ileges (that is, its pri!ileges column is null. .efault pri!ileges alwa*s include all pri!ileges for
the owner, and ma* include some pri!ileges for P:>L&, depending on the object t*pe, as explained
abo!e.
#he first 5RA6# or R0C1D0 on an object will instantiate the default pri!ileges (producing, for
example,
OmiriamHarwdRxtMmiriamP and then modif* them per the specified re/uest.
6otice that the owner8s implicit grant options are not mar)ed in the access pri!ileges displa*. A G
will appear onl* when grant options ha!e been explicitl* granted to someone.
E(amples
5rant insert pri!ilege to all users on table films2
0RA1T .1SERT !1 'ilms T! P,-L.C$
5rant all a!ailable pri!ileges to user manuel on !iew )inds2
0RA1T ALL PR.3.LE0ES !1 Kinds T! man&el$
6ote that while the abo!e will indeed grant all pri!ileges if executed b* a superuser or the owner of
)inds, when executed b* someone else it will onl* grant those permissions for which the someone
else has grant options.
5rant membership in role admins to user joe2
0RA1T admins T! 8oe$
,ompatibilit* According to the SQL standard, the PR&C&L050S )e* word in ALL PR&C&L050S is
re/uired. #he SQL standard does not support setting the pri!ileges on more than one object per
command.
PostgreSQL allows an object owner to re!o)e his own ordinar* pri!ileges2 for example, a table
owner can ma)e the table read4onl* to himself b* re!o)ing his own &6S0R#, :P.A#0, and
.0L0#0 pri!ileges.
#his is not possible according to the SQL standard. #he reason is that PostgreSQL treats the
owner8s pri!ileges as ha!ing been granted b* the owner to himself3 therefore he can re!o)e them
too. &n the SQL standard, the owner8s pri!ileges are granted b* an assumed entit* $7S=S#0+%. 6ot
being $7S=S#0+%, the owner cannot re!o)e these rights.
#he SQL standard allows setting pri!ileges for indi!idual columns within a table2
5RA6# pri!ileges
16 table I ( column I, ...J J I, ...J
#1 O P:>L&, K username I, ...J P I @&#? 5RA6# 1P#&16 J
#he SQL standard pro!ides for a :SA50 pri!ilege on other )inds of objects2 character sets,
collations, translations, domains.
#he R:L0 pri!ilege, and pri!ileges on databases, tablespaces, schemas, languages, and se/uences
are PostgreSQL extensions.
See Also
R0C1D0
RE3!4E
6ame
R0C1D0 E remo!e access pri!ileges
S*nopsis
RE3!4E = 0RA1T !PT.!1 !R >
F F SELECT ? .1SERT ? ,PDATE ? DELETE ? R,LE ? REERE1CES ? TR.00ER G
=2...> ? ALL = PR.3.LE0ES > G
!1 = TA-LE > tablename =2 ...>
R!" F &sername ? 0R!,P gro&pname ? P,-L.C G =2 ...>
= CASCADE ? RESTR.CT >
RE3!4E = 0RA1T !PT.!1 !R >
F F CREATE ? TE"P!RAR@ ? TE"P G =2...> ? ALL = PR.3.LE0ES > G
!1 DATA-ASE dbname =2 ...>
R!" F &sername ? 0R!,P gro&pname ? P,-L.C G =2 ...>
= CASCADE ? RESTR.CT >
R0C1D0 I 5RA6# 1P#&16 "1R J
O 0B0,:#0 K ALL I PR&C&L050S J P
16 ":6,#&16 funcname ( I I argmode J I argname J argt*pe I, ...J J I, ...J
"R1+ O username K 5R1:P groupname K P:>L&, P I, ...J
I ,AS,A.0 K R0S#R&,# J
R0C1D0 I 5RA6# 1P#&16 "1R J
O :SA50 K ALL I PR&C&L050S J P
16 LA65:A50 langname I, ...J
"R1+ O username K 5R1:P groupname K P:>L&, P I, ...J
I ,AS,A.0 K R0S#R&,# J
R0C1D0 I 5RA6# 1P#&16 "1R J
O O ,R0A#0 K :SA50 P I,...J K ALL I PR&C&L050S J P
16 S,?0+A schemaname I, ...J
"R1+ O username K 5R1:P groupname K P:>L&, P I, ...J
I ,AS,A.0 K R0S#R&,# J
R0C1D0 I 5RA6# 1P#&16 "1R J
O ,R0A#0 K ALL I PR&C&L050S J P
16 #A>L0SPA,0 tablespacename I, ...J
"R1+ O username K 5R1:P groupname K P:>L&, P I, ...J
I ,AS,A.0 K R0S#R&,# J
RE3!4E = AD".1 !PT.!1 !R >
role =2 ...> R!" &sername =2 ...>
= CASCADE ? RESTR.CT >
.escription
#he R0C1D0 command re!o)es pre!iousl* granted pri!ileges from one or more roles. #he )e*
word P:>L&, refers to the implicitl* defined group of all roles.
See the description of the 5RA6# command for the meaning of the pri!ilege t*pes.
6ote that an* particular role will ha!e the sum of pri!ileges granted directl* to it, pri!ileges granted
to an* role it is presentl* a member of, and pri!ileges granted to P:>L&,. #hus, for example,
re!o)ing S0L0,# pri!ilege from P:>L&, does not necessaril* mean that all roles ha!e lost
S0L0,# pri!ilege on the object2
those who ha!e it granted directl* or !ia another role will still ha!e it.
&f 5RA6# 1P#&16 "1R is specified, onl* the grant option for the pri!ilege is re!o)ed, not the
pri!ilege itself. 1therwise, both the pri!ilege and the grant option are re!o)ed.
&f a user holds a pri!ilege with grant option and has granted it to other users then the pri!ileges held
b* those other users are called dependent pri!ileges. &f the pri!ilege or the grant option held b* the
first user is being re!o)ed and dependent pri!ileges exist, those dependent pri!ileges are also
re!o)ed if ,AS,A.0 is specified, else the re!o)e action will fail. #his recursi!e re!ocation onl*
affects pri!ileges that were granted through a chain of users that is traceable to the user that is the
subject of this R0C1D0 command.
#hus, the affected users ma* effecti!el* )eep the pri!ilege if it was also granted through other
users.
@hen re!o)ing membership in a role, 5RA6# 1P#&16 is instead called A.+&6 1P#&16, but the
beha!ior is similar. 6ote also that this form of the command does not allow the noise word 5R1:P.
6otes
:se psql:s %H command to displa* the pri!ileges granted on existing objects. See 5RA6# for
information about the format.
A user can onl* re!o)e pri!ileges that were granted directl* b* that user. &f, for example, user A has
granted a pri!ilege with grant option to user >, and user > has in turned granted it to user ,, then
user A cannot re!o)e the pri!ilege directl* from ,. &nstead, user A could re!o)e the grant option
from user > and use the ,AS,A.0 option so that the pri!ilege is in turn re!o)ed from user ,. "or
another example, if both
A and > ha!e granted the same pri!ilege to ,, A can re!o)e his own grant but not >8s grant, so ,
will still effecti!el* ha!e the pri!ilege.
@hen a non4owner of an object attempts to R0C1D0 pri!ileges on the object, the command will
fail outright if the user has no pri!ileges whatsoe!er on the object. As long as some pri!ilege is
a!ailable, the command will proceed, but it will re!o)e onl* those pri!ileges for which the user has
grant options.
#he R0C1D0 ALL PR&C&L050S forms will issue a warning message if no grant options are held,
while the other forms will issue a warning if grant options for an* of the pri!ileges specificall*
named in the command are not held. (&n principle these statements appl* to the object owner as
well, but since the owner is alwa*s treated as holding all grant options, the cases can ne!er occur.
&f a superuser chooses to issue a 5RA6# or R0C1D0 command, the command is performed as
though it were issued b* the owner of the affected object. Since all pri!ileges ultimatel* come from
the object owner (possibl* indirectl* !ia chains of grant options, it is possible for a superuser to
re!o)e all pri!ileges, but this ma* re/uire use of ,AS,A.0 as stated abo!e.
R0C1D0 can also be done b* a role that is not the owner of the affected object, but is a member of
the role that owns the object, or is a member of a role that holds pri!ileges @&#? 5RA6# 1P#&16
on the object.
&n this case the command is performed as though it were issued b* the containing role that actuall*
owns the object or holds the pri!ileges @&#? 5RA6# 1P#&16. "or example, if table t( is owned
b* role g(, of which role u( is a member, then u( can re!o)e pri!ileges on t( that are recorded as
being granted b* g(.
#his would include grants made b* u( as well as b* other members of role g(.
&f the role executing R0C1D0 holds pri!ileges indirectl* !ia more than one role membership path,
it is unspecified which containing role will be used to perform the command. &n such cases it is best
practice to use S0# R1L0 to become the specific role *ou want to do the R0C1D0 as. "ailure to
do so ma* lead to re!o)ing pri!ileges other than the ones *ou intended, or not re!o)ing an*thing at
all.
E(amples
Re!o)e insert pri!ilege for the public on table films2
RE3!4E .1SERT !1 'ilms R!" P,-L.C$
Re!o)e all pri!ileges from user manuel on !iew )inds2
RE3!4E ALL PR.3.LE0ES !1 Kinds R!" man&el$
6ote that this actuall* means $re!o)e all pri!ileges that & granted%.
Re!o)e membership in role admins from user joe2
RE3!4E admins R!" 8oe$
,ompatibilit*
#he compatibilit* notes of the 5RA6# command appl* analogousl* to R0C1D0. #he s*ntax
summar* is2
R0C1D0 I 5RA6# 1P#&16 "1R J pri!ileges
16 object I ( column I, ...J J
"R1+ O P:>L&, K username I, ...J P
O R0S#R&,# K ,AS,A.0 P
1ne of R0S#R&,# or ,AS,A.0 is re/uired according to the standard, but PostgreSQL assumes
R0S#R&,# b* default.
See Also
ALTER ROLE
Name
AL#0R R1L0 44 change a database role
Synopsis
ALTER ROLE name [ [ WITH ] option [ ... ] ]
where option can be:
SUPERUSER | OSUPERUSER
| !REATE"# | O!REATE"#
| !REATEROLE | O!REATEROLE
| !REATEUSER | O!REATEUSER
| IHERIT | OIHERIT
| LO$I | OLO$I
| REPLI!ATIO | OREPLI!ATIO
| !OE!TIO LI%IT conn&imit
| [ E!R'PTE" | UE!R'PTE" ] PASSWOR" (pa))wor*(
| +ALI" UTIL (time)tamp(
ALTER ROLE name REA%E TO new,name
ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] SET con-i./ration,parameter 0 TO |
1 2 0 3a&/e | "E4AULT 2
ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] SET con-i./ration,parameter 4RO%
!URRET
ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] RESET con-i./ration,parameter
ALTER ROLE name [ I "ATA#ASE *ataba)e,name ] RESET ALL
Description
ALTER ROLE changes the attributes of a PostgreSQL role.
#he first !ariant of this command listed in the s*nopsis can change man* of the role attributes that
can be specified in ,R0A#0 R1L0. (All the possible attributes are co!ered, except that there are no
options for adding or remo!ing memberships3 use 5RA6# and R0C1D0 for that. Attributes not
mentioned in the command retain their pre!ious settings. .atabase superusers can change an* of
these settings for an* role. Roles ha!ing !REATEROLE pri!ilege can change an* of these settings,
but onl* for non4superuser and non4replication roles. 1rdinar* roles can onl* change their own
password.
#he second !ariant changes the name of the role. .atabase superusers can rename an* role. Roles
ha!ing !REATEROLE pri!ilege can rename non4superuser roles. #he current session user cannot be
renamed. (,onnect as a different user if *ou need to do that. >ecause %"54encr*pted passwords
use the role name as cr*ptographic salt, renaming a role clears its password if the password is %"54
encr*pted.
#he remaining !ariants change a roleTs session default for a configuration !ariable, either for all
databases or, when the I "ATA#ASE clause is specified, onl* for sessions in the named database.
@hene!er the role subse/uentl* starts a new session, the specified !alue becomes the session
default, o!erriding whate!er setting is present in po)t.re)6&.con- or has been recei!ed from
the po)t.re) command line. #his onl* happens at login time3 executing S0# R1L0 or S0#
S0SS&16 A:#?1R&UA#&16 does not cause new configuration !alues to be set. Settings set for all
databases are o!erridden b* database4specific settings attached to a role. Superusers can change
an*oneTs session defaults. Roles ha!ing !REATEROLE pri!ilege can change defaults for non4
superuser roles. 1rdinar* roles can onl* set defaults for themsel!es. ,ertain configuration !ariables
cannot be set this wa*, or can onl* be set if a superuser issues the command.
Parameters
name
#he name of the role whose attributes are to be altered.
SUPERUSER
OSUPERUSER
!REATE"#
O!REATE"#
!REATEROLE
O!REATEROLE
!REATEUSER
O!REATEUSER
IHERIT
OIHERIT
LO$I
OLO$I
REPLI!ATIO
OREPLI!ATIO
!OE!TIO LI%IT conn&imit
PASSWOR" pa))wor*
E!R'PTE"
UE!R'PTE"
+ALI" UTIL Ttime)tampT
#hese clauses alter attributes originall* set b* ,R0A#0 R1L0. "or more information, see the
!REATE ROLE reference page.
new,name
#he new name of the role.
*ataba)e,name
#he name of the database the configuration !ariable should be set in.
con-i./ration,parameter
3a&/e
Set this roleTs session default for the specified configuration parameter to the gi!en !alue. &f
3a&/e is "E4AULT or, e/ui!alentl*, RESET is used, the role4specific !ariable setting is
remo!ed, so the role will inherit the s*stem4wide default setting in new sessions. :se RESET
ALL to clear all role4specific settings. SET 4RO% !URRET sa!es the sessionTs current
!alue of the parameter as the role4specific !alue. &f I "ATA#ASE is specified, the
configuration parameter is set or remo!ed for the gi!en role and database onl*.
Role4specific !ariable settings ta)e effect onl* at login3 S0# R1L0 and S0# S0SS&16
A:#?1R&UA#&16 do not process role4specific !ariable settings.
See S0# and ,hapter (' for more information about allowed parameter names and !alues.
Notes
:se ,R0A#0 R1L0 to add new roles, and .R1P R1L0 to remo!e a role.
ALTER ROLE cannot change a roleTs memberships. :se 5RA6# and R0C1D0 to do that.
,aution must be exercised when specif*ing an unencr*pted password with this command. #he
password will be transmitted to the ser!er in cleartext, and it might also be logged in the clientTs
command histor* or the ser!er log. ps/l contains a command 7pa))wor* that can be used to
change a roleTs password without exposing the cleartext password.
&t is also possible to tie a session default to a specific database rather than to a role3 see AL#0R
.A#A>AS0. &f there is a conflict, database4role4specific settings o!erride role4specific ones, which
in turn o!erride database4specific ones.
Examples
,hange a roleTs password2
ALTER ROLE *a3i*e WITH PASSWOR" (h/89mn:(;
Remo!e a roleTs password2
ALTER ROLE *a3i*e WITH PASSWOR" ULL;
,hange a password expiration date, specif*ing that the password should expire at midda* on Nth
+a* ;<(- using the time 9one which is one hour ahead of :#,2
ALTER ROLE chri) +ALI" UTIL (%a< = >?:@@:@@ ?@>5 A>(;
+a)e a password !alid fore!er2
ALTER ROLE -re* +ALI" UTIL (in-init<(;
5i!e a role the abilit* to create other roles and new databases2
ALTER ROLE miriam !REATEROLE !REATE"#;
5i!e a role a non4default setting of the maintenance7wor)7mem parameter2
ALTER ROLE worBer,bee SET maintenance,worB,mem 1 >@@@@@;
5i!e a role a non4default, database4specific setting of the client7min7messages parameter2
ALTER ROLE -re* I "ATA#ASE *e3e& SET c&ient,min,me))a.e) 1 "E#U$;