Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CA+TgmoZMuUm8vuVQ6yLzrKx=W_7WVP6QeRNHtntb1UMg7X7S9w@mail.gmail.com>
Date: Wed, 17 Nov 2021 07:57:41 -0800
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D471843D-16FE-49D2-8E39-EA4EC54DAC11@enterprisedb.com>
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>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/D471843D-16FE-49D2-8E39-EA4EC54DAC11%40enterprisedb.com>
Precedence: bulk


> On Nov 17, 2021, at 5:32 AM, Robert Haas <robertmhaas@gmail.com> =
wrote:
>=20
>> 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.
>=20
> 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 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.)
>=20
> 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 the toast 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:
>=20
> 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, and also 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 would work.  I was not =
proposing to do it that way.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company