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