PG Doc comments form <noreply@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