createrole_self_grant

Definition PG 18 manual

If a user who has CREATEROLE but not SUPERUSER creates a role, and if this is set to a non-empty value, the newly-created role will be granted to the creating user with the options specified. The value must be set, inherit, or a comma-separated list of these. The default value is an empty string, which disables the feature.

The purpose of this option is to allow a CREATEROLE user who is not a superuser to automatically inherit, or automatically gain the ability to SET ROLE to, any created users. Since a CREATEROLE user is always implicitly granted ADMIN OPTION on created roles, that user could always execute a GRANT statement that would achieve the same effect as this setting. However, it can be convenient for usability reasons if the grant happens automatically. A superuser automatically inherits the privileges of every role and can always SET ROLE to any role, and this setting can be used to produce a similar behavior for CREATEROLE users for users which they create.

How it works

createrole_self_grant sets whether a CREATEROLE user automatically grants the role to themselves, and with which options. An empty string disables automatic self grants. The accepted options are set, inherit, or both; it automates a grant the creating CREATEROLE user could issue with ADMIN OPTION and does not affect superusers.

createrole_self_grant is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Because session state can survive in pooled connections, role defaults, SET privilege, RESET behavior, and application checkout hooks are part of the control's effective boundary.

Operational considerations

Changing createrole_self_grant in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Granting broad SET rights to a control that can change correctness, policy enforcement, or name resolution.

Failing to reset a security-sensitive session value before a pooled connection is reused by another request.

Changing createrole_self_grant globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Use a dedicated analytical role if createrole_self_grant must differ, and verify that exports, triggers, policies, and name resolution still preserve data correctness.

OLTP: Treat createrole_self_grant as a correctness or security control, not a throughput knob. Grant SET authority narrowly and establish it from trusted role or application policy.

SMALL: Keep createrole_self_grant at its safe default unless a documented repair or compatibility workflow requires otherwise; record and automatically restore temporary changes.