Message-ID: <e95680ff-2015-115f-2d8d-99ad139e678e@dunslane.net>
Date: Wed, 17 Nov 2021 09:24:39 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>,
 Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com>
 <CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
 <2226110.1637075835@sss.pgh.pa.us>
 <CA+TgmoYWqjpHEogdCEbRwzUb5ZoEaUt8ciNUXFCwLZDWBe+_BA@mail.gmail.com>
 <2226903.1637076537@sss.pgh.pa.us>
 <A6157072-B564-4171-8599-068C8D65BE9C@enterprisedb.com>
 <2231899.1637081047@sss.pgh.pa.us>
 <38BEC583-DB34-4918-BCBC-DC896F0D3844@enterprisedb.com>
 <055d86ff-9c95-f1d4-c974-29896767561e@dunslane.net>
 <7DFFECF0-373B-40B0-BCA0-A5ADD9266FFA@enterprisedb.com>
 <2347082.1637100769@sss.pgh.pa.us>
 <8F320DC8-C312-40C0-AF41-7B3D8F21584A@enterprisedb.com>
 <CA+TgmoZMuUm8vuVQ6yLzrKx=W_7WVP6QeRNHtntb1UMg7X7S9w@mail.gmail.com>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: 
 <CA+TgmoZMuUm8vuVQ6yLzrKx=W_7WVP6QeRNHtntb1UMg7X7S9w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/e95680ff-2015-115f-2d8d-99ad139e678e%40dunslane.net>
Precedence: bulk


On 11/17/21 08:32, Robert Haas wrote:
> 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 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