Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1mn0OQ-0005AE-FG
	for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Nov 2021 15:29:06 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1mn0OP-0006HR-6c
	for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Nov 2021 15:29:05 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mn0OO-0006HI-PH
	for pgsql-hackers@lists.postgresql.org; Tue, 16 Nov 2021 15:29:04 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mn0OM-0000kf-Iz
	for pgsql-hackers@postgresql.org; Tue, 16 Nov 2021 15:29:03 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 1AGFSv1M2226904;
	Tue, 16 Nov 2021 10:28:57 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Mark Dilger <mark.dilger@enterprisedb.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
In-reply-to: 
 <CA+TgmoYWqjpHEogdCEbRwzUb5ZoEaUt8ciNUXFCwLZDWBe+_BA@mail.gmail.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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 16 Nov 2021 10:23:27 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2226902.1637076537.1@sss.pgh.pa.us>
Date: Tue, 16 Nov 2021 10:28:57 -0500
Message-ID: <2226903.1637076537@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/2226903.1637076537%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 16, 2021 at 10:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Right.  I think that any design that involves per-GUC catalog entries
>> is going to be an abysmal failure, precisely because the set of GUCs
>> is not stable enough.

> In practice it's pretty stable. I think it's just a matter of having a
> plan that covers the cases where it isn't stable reasonably elegantly.

Um.  Really the point comes down to having sane default behavior
when there's no entry, which ought to eliminate any need to do the
sort of "run over all the entries at startup" processing that you
seemed to be proposing.  So I guess I don't understand why such a
thing would be needed.

> We already embed GUC names in catalog entries when someone runs ALTER
> USER SET or ALTER DATABASE SET, so this proposal doesn't seem to be
> moving the goalposts in any meaningful way.

True; as long as the expectation is that entries will exist for only
a tiny subset of GUCs, it's probably fine.

			regards, tom lane