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 1qsQSx-008082-3E for pgsql-docs@arkaria.postgresql.org; Mon, 16 Oct 2023 16:29:15 +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 1qsQSv-002bpJ-2Z for pgsql-docs@arkaria.postgresql.org; Mon, 16 Oct 2023 16:29:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsQSu-002bon-RP for pgsql-docs@lists.postgresql.org; Mon, 16 Oct 2023 16:29:13 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qsQSt-000mOY-04 for pgsql-docs@lists.postgresql.org; Mon, 16 Oct 2023 16:29:12 +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 39GGT9O22307199; Mon, 16 Oct 2023 12:29:09 -0400 From: Tom Lane To: gavinpanella@gmail.com cc: 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: <169746329791.169914.16613647309012285391@wrigleys.postgresql.org> References: <169746329791.169914.16613647309012285391@wrigleys.postgresql.org> Comments: In-reply-to PG Doc comments form message dated "Mon, 16 Oct 2023 13:34:57 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2307197.1697473749.1@sss.pgh.pa.us> Date: Mon, 16 Oct 2023 12:29:09 -0400 Message-ID: <2307198.1697473749@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Doc comments form writes: > As far as I can tell, the following statement: >> PostgreSQL will accept a setting for any two-part parameter name > does not hold when creating a *new* setting with `ALTER SYSTEM`, e.g. > ALTER SYSTEM SET foo.bar TO 'baz'; > will elicit an error. ALTER SYSTEM requires the variable to be known, so that (a) it can figure out whether you have permissions to set it at system level, and (b) it can check the validity of the value. It does not seem like a good idea to allow unchecked values to be pushed into the config file, because a mistake would prevent future server restarts from succeeding. If you just do "SET foo.bar = whatever", the action is transiently allowed because nothing very interesting will happen until/unless some extension loads a definition of the variable into your session, and we can figure out at that point whether your setting should be accepted. It would be too much of a mess to make that work for ALTER SYSTEM though, not least because the config files don't record who set the variable. I do see an issue here: regression=# ALTER SYSTEM SET foo.bar TO 'baz'; ERROR: unrecognized configuration parameter "foo.bar" regression=# SET foo.bar TO 'baz'; SET regression=# ALTER SYSTEM SET foo.bar TO 'baz'; ALTER SYSTEM and now we have $ cat $PGDATA/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. foo.bar = 'baz' 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. I wonder though if forbidding this would break any legitimate usage patterns. regards, tom lane