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 ) id 1nUqYW-0000hE-By for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Mar 2022 13:52:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nUqYV-0001Ih-7E for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Mar 2022 13:52:43 +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 ) id 1nUqYU-0001IY-T0 for pgsql-hackers@lists.postgresql.org; Thu, 17 Mar 2022 13:52:42 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUqYR-0000YN-K1 for pgsql-hackers@postgresql.org; Thu, 17 Mar 2022 13:52:41 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8C4AD3200F9F; Thu, 17 Mar 2022 09:52:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 17 Mar 2022 09:52:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=WaEySSrGyZq8si+YuWAJFbXyHNCefx/KLb4REye7u 9c=; b=LQaTrOM06RHYbAbMpXCNfAF6gO/UKtISp0RULdMWrsK6qcTm6fPIy60qt 5gtUy9G09ReClEYz8ezjQWr65Wigd43ThTqYWFU/VlzLx48kyHm57nZL0fRRYOWZ UN32tDkPYIuyO5izIvVEHi4UkLW021ZBQzoy9jJb6e7YrpkWrntgp7fzISVYJHYG 0pWIO86JltZCxGyPxo3Rviq3XKqwP8M71oFf60HBC2DF40EAkzFkGrAt4K6ErsS+ v7TjKPQXinHANhF5xIFGOd2Ca7Hc5JMtEf2RnlKW/oTEeS6kVzDvR6xm6vCpBTCr b1y/hu6WuvjIdo/pYqoHyZbiBQVwQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefgedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepfeejgeehteeuhfevvedu leeufedtjeetiefftedvudfhtdeifefgueettdevgefgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Mar 2022 09:52:35 -0400 (EDT) Message-ID: <85c84295-6a1b-80ac-b9c4-62413a8e5b60@enterprisedb.com> Date: Thu, 17 Mar 2022 14:52:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs Content-Language: en-US To: Mark Dilger , Tom Lane Cc: Andrew Dunstan , Joshua Brindle , Robert Haas , Jeff Davis , PostgreSQL-development , Joe Conway References: <3D691E20-C1D5-4B80-8BA5-6BEB63AF3029@enterprisedb.com> <9DB8DABC-0E1E-4AB0-BB11-9BC48E4C71BE@enterprisedb.com> <2D6C1081-DB7D-4260-8987-5B4912E95917@enterprisedb.com> <1A6DA47B-2D5F-427E-AD72-1D8BD23BF94C@enterprisedb.com> <79685.1646604824@sss.pgh.pa.us> <83814.1646607430@sss.pgh.pa.us> <78889A65-CA7A-4015-866D-33460967071D@enterprisedb.com> <92485.1646609263@sss.pgh.pa.us> <43857434-3f9b-3! 66f-0401-7aea558827e1@dunslane.net> <664799.1647456444@sss.pgh.pa.us> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 16.03.22 19:59, Mark Dilger wrote: > Informally, we often use "GUC" on this list, but that isn't used formally, leaving "configuration parameter" and "setting" as the two obvious choices. I preferred "configuration parameter" originally and was argued out of it. My take on "setting" was also that it more naturally refers to the choice of setting, not the thing being set, such that "work_mem = 8192" means the configuration parameter "work_mem" has the setting "8192". "The current setting of the work_mem parameter is 8192." I think something based on "parameter" is good. We also use that language in the protocol (e.g., ParameterStatus).