| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Granting SET and ALTER SYSTE privileges for GUCs |
| Date: | 2021-11-17 14:24:39 |
| Message-ID: | e95680ff-2015-115f-2d8d-99ad139e678e@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/17/21 08:32, Robert Haas wrote:
> On Tue, Nov 16, 2021 at 5:45 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)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.
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 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.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xiaozhe Yao | 2021-11-17 14:28:53 | Re: Propose a new hook for mutating the query bounds |
| Previous Message | Daniel Gustafsson | 2021-11-17 14:11:24 | Re: VS2022: Support Visual Studio 2022 on Windows |