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

* Amit Kapila (amit.kapila16@gmail.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
itis, 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
somethingthey 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
thana simple filename. 

There are probably other considerations also..
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: docbook-xsl version for release builds
Next
From: Merlin Moncure
Date:
Subject: Re: PL/pgSQL, RAISE and error context