Re: Granting SET and ALTER SYSTE privileges for GUCs
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-11-17T13:32:27Z
Lists: pgsql-hackers
On Tue, Nov 16, 2021 at 5:45 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > I was aware of that, but figured not all GUCs have to be grantable. If it doesn't fit in a NameData, you can't grant on it. Such restrictions are rather counterintuitive for users, and here it doesn't even buy anything. Using 'text' rather than 'name' as the data type isn't going to cost any meaningful amount of performance. > If we want to be more accommodating than that, we can store it as text, just like pg_db_role_names does, but then we need more code complexity to look it up and to verify that it is unique. (We wouldn't want multiple records for the same <role,guc> pair.) If you're verifying that it's unique in any way other than using a unique index, I think you're doing it wrong. Also, maybe I'm confused here, but why isn't the schema: gucoid gucname gucacl IOW, I don't understand why this table has <role,guc> as the primary key rather than just guc. Everywhere else, we have a single ACL array for the all privileges on an object. Why wouldn't we do the same thing here? -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 landed