Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit(dot)kapila16(at)gmail(dot)com) wrote:
> This can resolve the problem of whether to read auto file rather
> cleanly, so the idea is:
>
> Enable/Disable reading of auto file
> -----------------------------------------------------
> a. Have a new include in postresql.conf
> #include_auto_conf_file postgresql.auto.conf
> as it is a special include, we can read this file relative to data
> directory.
>
> Enable/Disable Alter System command
> -----------------------------------------------------------
> This can be achieved in 3 ways:
> a. Check before executing Alter System if include directive is
> disabled, then just issue a warning to user and proceed with command.
> b. Check before executing Alter System if include directive is
> disabled, then just issue an error and stop.

It doesn't make sense for it to be a 'warning' with this- the
parameter specifies the file to use. If you don't know what file to
use, how you can possibly do anything but return an error?

Note that I *like* that about this approach.

There are a few other considerations with this-

- What should the default be? (Still thinking 'off' myself)
- What happens if the user specifies 'postgresql.conf'? I'm thinking we
would disallow such insanity (as that's what it is, imv..) by having
an identifier in the file that this is the PG "auto conf" file.
- Should we have such an identifier in auto.conf to indicate that we
created it, to prevent the user from setting it to something they
shouldn't?
- What's the "bootstrap" mode; iow, if a user enables the option but the
file doesn't exist, what do we do? With this approach, I'd be
inclined to say we simply create it and put the marker to indicate
it's "our" file.
- Should we allow it to be outside of the data dir? We could simply log
an error and ignore the parameter if it's more than a simple filename.

There are probably other considerations also..

Thanks,

Stephen