Re: Granting SET and ALTER SYSTE privileges for GUCs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Granting SET and ALTER SYSTE privileges for GUCs
Date
Msg-id CA+TgmoZMuUm8vuVQ6yLzrKx=W_7WVP6QeRNHtntb1UMg7X7S9w@mail.gmail.com
Whole thread Raw
In response to Re: Granting SET and ALTER SYSTE privileges for GUCs  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Granting SET and ALTER SYSTE privileges for GUCs
Re: Granting SET and ALTER SYSTE privileges for GUCs
List 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
onit. 

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
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.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Next
From: Daniel Gustafsson
Date:
Subject: Re: Yet another fast GiST build