PG Doc comments form <nore...@postgresql.org> 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