{"Entry":{"collection":"guc","key":"createrole_self_grant","name":"createrole_self_grant","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Client Connection Defaults / Statement Behavior","category_zh":"","changed_in":["18"],"changes":[{"documentation_changed":false,"fields":{},"from":"15","status":"added","to":"16"},{"documentation_changed":false,"fields":{"extra_desc":{"from":null,"to":"An empty string disables automatic self grants."}},"from":"17","status":"changed","to":"18"}],"content_hash":"2267646214ad197332a6dd3cab185761b9fde46ea5a50e3248251ade0753b18c","context":"","default_changed_in":[],"default_history":[{"from":"16","to":"19","value":"Empty string"}],"derived_content_hash":"c68ac0aa0593cfb7956937192bbb761a828f020caecc891b0ba973a65b98c40c","editorial":{"advice":{"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."},"mechanism":["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."],"pitfalls":["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."],"references":[{"title":"PostgreSQL 19 Beta 4: createrole_self_grant","url":"https://www.postgresql.org/docs/19/runtime-config-client.html#GUC-CREATEROLE-SELF-GRANT"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["search_path","row_security","session_replication_role","event_triggers","restrict_nonsystem_relation_kind"],"summary":"createrole_self_grant is the PostgreSQL setting that defines whether a CREATEROLE user automatically grants the role to themselves, and with which options."},"enumvals":[],"first_version":"16","group":"Client Connection Defaults","group_slug":"client","imported_at":"2026-09-27T17:57:30.997196+08:00","intro_commit":{"authored_at":"2023-01-10T12:44:49-05:00","discussion":["https://postgr.es/m/CA+TgmobN59ct+Emmz6ig1Nua2Q-_o=r6DSD98KfU53kctq_kQw@mail.gmail.com"],"hash":"e5b8a4c098ad6add39626a14475148872cd687e0","subject":"Add new GUC createrole_self_grant.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5b8a4c098ad6add39626a14475148872cd687e0"},"key":"createrole_self_grant","last_version":"20","max_val":"","min_val":"","name":"createrole_self_grant","position":73,"present_in":["16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:4fe880d8d185142dd83970fc23b0ddef1e98ddd361ec41c93b2e7a76b4f87d94","receipt_sha256":"4eaa94c024b6edda64b4228788ea78dfe5654e1435b7798dfac8b1b177dbaa81","repair":"wiki-repair-20261023"},"short_desc":"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.","short_desc_zh":"","source_rev":"wiki-repair-20261023:35a340d4e60f89320f94540a64cc29b3509aff1f7c94c9b57debae29c2c5f555","unit":"","vartype":"string"}},"Definition":{"Collection":"guc","Key":"createrole_self_grant","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"createrole_self_grant","SourceRevision":"wiki-repair-20261023:35a340d4e60f89320f94540a64cc29b3509aff1f7c94c9b57debae29c2c5f555","Facts":{"boot_val":"","category":"Client Connection Defaults / Statement Behavior","context":"user","description":"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.","description_zh":"如果一个拥有 CREATEROLE 但不拥有 SUPERUSER 权限的用户创建了角色，并且此选项被设置为非空值，则新创建的角色将以指定选项授予创建者。该值必须是 set、inherit 或它们的逗号分隔列表。默认值为空字符串，这会禁用此功能。 此选项的目的是允许非超级用户的 CREATEROLE 用户自动继承所创建用户的权限，或自动获得对这些用户执行 SET ROLE 的能力。由于 CREATEROLE 用户始终会隐式获得其所创建角色的 ADMIN OPTION，因此该用户总是可以通过执行 GRANT 语句达到相同效果，但自动授予在可用性上更方便。超级用户会自动继承每个角色的权限，并且始终可以对任何角色执行 SET ROLE；此设置可让 CREATEROLE 用户对其创建的用户获得类似的行为。","description_zh_html":"\u003cp\u003e\n\t        如果一个拥有 \u003ccode class=\"literal\"\u003eCREATEROLE\u003c/code\u003e 但不拥有 \u003ccode class=\"literal\"\u003eSUPERUSER\u003c/code\u003e 权限的用户创建了角色，并且此选项被设置为非空值，则新创建的角色将以指定选项授予创建者。该值必须是 \u003ccode class=\"literal\"\u003eset\u003c/code\u003e、\u003ccode class=\"literal\"\u003einherit\u003c/code\u003e 或它们的逗号分隔列表。默认值为空字符串，这会禁用此功能。\n\t       \u003c/p\u003e\u003cp\u003e\n\t        此选项的目的是允许非超级用户的 \u003ccode class=\"literal\"\u003eCREATEROLE\u003c/code\u003e 用户自动继承所创建用户的权限，或自动获得对这些用户执行 \u003ccode class=\"literal\"\u003eSET ROLE\u003c/code\u003e 的能力。由于 \u003ccode class=\"literal\"\u003eCREATEROLE\u003c/code\u003e 用户始终会隐式获得其所创建角色的 \u003ccode class=\"literal\"\u003eADMIN OPTION\u003c/code\u003e，因此该用户总是可以通过执行 \u003ccode class=\"literal\"\u003eGRANT\u003c/code\u003e 语句达到相同效果，但自动授予在可用性上更方便。超级用户会自动继承每个角色的权限，并且始终可以对任何角色执行 \u003ccode class=\"literal\"\u003eSET ROLE\u003c/code\u003e；此设置可让 \u003ccode class=\"literal\"\u003eCREATEROLE\u003c/code\u003e 用户对其创建的用户获得类似的行为。\n\t       \u003c/p\u003e","doc":{"anchor":"GUC-CREATEROLE-SELF-GRANT","file":"runtime-config-client.html","lang":"en","sha256":"6be6cc70f29eca4695dc43b2b2b94c75b7e0eaaa2c00273d7a98488917a7edb7","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"An empty string disables automatic self grants.","lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"createrole_self_grant","short_desc":"Sets whether a CREATEROLE user automatically grants the role to themselves, and with which options.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-client.html","sha256":"1882f8fd5576909c4fcc44af53077378871e05f5be67723f20fe300273024767"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":null,"vartype":"string","zh_from":"same-version-pgdoc"},"ManualEvidence":{"doc":{"anchor":"GUC-CREATEROLE-SELF-GRANT","file":"runtime-config-client.html","lang":"en","sha256":"6be6cc70f29eca4695dc43b2b2b94c75b7e0eaaa2c00273d7a98488917a7edb7","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"createrole_self_grant","SourceDatabase":"center","Version":"18","Locale":"en","Title":"createrole_self_grant","Summary":"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.","BodyHTML":"\u003cp\u003eIf 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.\u003c/p\u003e","SourceRevision":"wiki-repair-20261023:35a340d4e60f89320f94540a64cc29b3509aff1f7c94c9b57debae29c2c5f555","ContentHash":"1c22f13864e092c0fbcba59391bf82d735b1d01576c63401564cd5368043862d","Payload":{"description":"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."}},"RequestedLocale":"en","Fallback":false,"Versions":["16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}
