Thread: why is PG_AUTOCONF_FILENAME is pg_config_manual.h?
Surely that's not a value that we expect users to be able to edit. Is pg_config_manual.h just abused as a place that's included everywhere? (I suggest utils/guc.h as a better place.)
On Thu, Nov 27, 2014 at 11:58 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Surely that's not a value that we expect users to be able to edit. Is > pg_config_manual.h just abused as a place that's included everywhere? > > (I suggest utils/guc.h as a better place.) +1 Regards, -- Fujii Masao
On Thu, Nov 27, 2014 at 8:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>
> Surely that's not a value that we expect users to be able to edit. Is
> pg_config_manual.h just abused as a place that's included everywhere?
>
>
> Surely that's not a value that we expect users to be able to edit. Is
> pg_config_manual.h just abused as a place that's included everywhere?
>
Changing PG_AUTOCONF_FILENAME even by developer would
lead to loss of useful configuration settings (if any done by user via
ALTER SYSTEM) and on starting server user will see some
log message indicating that it has skipped processing configuration
file. I think the impact of changing this define is not so severe that
someone has to do initdb, however it's non-ignorable impact.
The file header of pg_config_manual.h seems to suggest that this
file contains such parameters.
On Thu, Nov 27, 2014 at 12:56 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Thu, Nov 27, 2014 at 11:58 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >> Surely that's not a value that we expect users to be able to edit. Is >> pg_config_manual.h just abused as a place that's included everywhere? >> >> (I suggest utils/guc.h as a better place.) > > +1 +1 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11/27/14 9:58 AM, Peter Eisentraut wrote: > Surely that's not a value that we expect users to be able to edit. Is > pg_config_manual.h just abused as a place that's included everywhere? > > (I suggest utils/guc.h as a better place.) This has been fixed.