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

From Mark Dilger
Subject Re: Granting SET and ALTER SYSTE privileges for GUCs
Date
Msg-id D471843D-16FE-49D2-8E39-EA4EC54DAC11@enterprisedb.com
Whole thread Raw
In response to Re: Granting SET and ALTER SYSTE privileges for GUCs  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

> On Nov 17, 2021, at 5:32 AM, Robert Haas <robertmhaas@gmail.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.

That sounds fine.

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

No, I'm using a unique index.  I was overthinking it, concerned about changing from name_ops to text_ops and needing
thetoast table, but that's silly, because I need one for the acl anyway. 

> Also, maybe I'm confused here, but why isn't the schema:
>
> gucoid
> gucname
> gucacl

It is, both in v2 already posted, and in the v3, written but not yet posted, as I haven't finished the pg_dump work,
andalso I'm waiting to see how this discussion gets resolved before asking for a review of v3. 

> IOW, I don't understand why this table has <role,guc> as the primary
> key rather than just guc.

I was responding to Tom's recommendation that I follow the pattern in pg_db_role_setting, and speculating how that
wouldwork.  I was not proposing to do it that way. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Non-superuser subscription owners
Next
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15