Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsU5X-008EtR-Nl for pgsql-docs@arkaria.postgresql.org; Mon, 16 Oct 2023 20:21:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qsU5U-0040ct-73 for pgsql-docs@arkaria.postgresql.org; Mon, 16 Oct 2023 20:21:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsU5T-0040cX-Vi for pgsql-docs@lists.postgresql.org; Mon, 16 Oct 2023 20:21:16 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsU5Q-0013aK-3E for pgsql-docs@lists.postgresql.org; Mon, 16 Oct 2023 20:21:15 +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 39GKL9432508785; Mon, 16 Oct 2023 16:21:10 -0400 From: Tom Lane To: Laurenz Albe cc: gavinpanella@gmail.com, pgsql-docs@lists.postgresql.org Subject: =?UTF-8?Q?Re:_"20.16._Customized_Options"_=E2=80=93=C2=A0cannot_b?= =?UTF-8?Q?e_set_by_`ALTER_SYSTEM`?= In-reply-to: <19600510deacf21b05a2c76bc3bde8d1283c77e3.camel@cybertec.at> References: <169746329791.169914.16613647309012285391@wrigleys.postgresql.org> <2307198.1697473749@sss.pgh.pa.us> <19600510deacf21b05a2c76bc3bde8d1283c77e3.camel@cybertec.at> Comments: In-reply-to Laurenz Albe message dated "Mon, 16 Oct 2023 19:37:46 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2508783.1697487669.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2023 16:21:09 -0400 Message-ID: <2508784.1697487669@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Laurenz Albe writes: > On Mon, 2023-10-16 at 12:29 -0400, Tom Lane wrote: >> So that feels like a bug: we should not allow ALTER SYSTEM to execute >> against a placeholder GUC definition, because the placeholder can't >> tell us whether the value is valid.=C2=A0 I wonder though if forbidding >> this would break any legitimate usage patterns. > I feel the same. However, the lack of any "variables" in SQL (as propos= ed > in [1]) leads a lot of people to abuse placeholder parameters as variabl= es > to hold application state. I am sure that that is where this complaint > comes from. We maintain that doing so is not a valid use case, but that= claim > sounds increasingly like a grammarian declaring that sentences should no= t > end with a preposition, when everybody does it all the time. Yeah, and we have been slowly removing the issues that made us not want to recommend using them like that. Anyway, I realized that I was wrong to claim that we need ALTER SYSTEM to defend us against bogus values of extension parameters in the config file. Checking is an important thing to do for core parameters, but a faulty extension parameter doesn't stop the system from booting. That's because we'll apply all the config file entries before we load any extensions, even ones listed in shared_preload_libraries. When we do load an extension, if it doesn't like what it finds in a placeholder then you get a WARNING and the parameter's default value is substituted. So there's no risk of an unstartable system. So maybe we should allow ALTER SYSTEM for unrecognized parameters, as long as the parameter name is syntactically legit and you're a superuser. regards, tom lane