Re: Granting SET and ALTER SYSTE privileges for GUCs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: 2021-11-17 13:32:27
Message-ID: CA+TgmoZMuUm8vuVQ6yLzrKx=W_7WVP6QeRNHtntb1UMg7X7S9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-11-17 13:33:41 Re: Yet another fast GiST build
Previous Message Robert Haas 2021-11-17 13:27:59 Re: Granting SET and ALTER SYSTE privileges for GUCs