Re: Granting SET and ALTER SYSTE privileges for GUCs
От | Andrew Dunstan |
---|---|
Тема | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Дата | |
Msg-id | e95680ff-2015-115f-2d8d-99ad139e678e@dunslane.net обсуждение исходный текст |
Ответ на | Re: Granting SET and ALTER SYSTE privileges for GUCs (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 11/17/21 08:32, Robert Haas wrote: > 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 granton 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. indeed >> 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 needmore 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. yeah > > 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? > Yes, that should work, It seems like a better scheme. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: