Tom Lane wrote:
>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>
>>How about *requiring* to set any variable, at least to xxx='default'?
>>
>>
>
>Don't like that ... we are not in the fascism business here ;-).
>
>
Well enforcing setting variables, in the presence of a preconfigured
file isn't exactly fascism... But I'm not surprised to read your
objection :-)
>How would you enforce it anyway?
>
>
Each cfg var would need a 'touched' flag. On startup, an ERROR is
thrown, on SIGHUP a WARNING. Or just a warning, stating which value is
actually used?
WARNING: xxx not set, using (default) value yyy.
>The idea of special-casing
> var = default
>(with no quotes around 'default') doesn't seem unreasonable, but
>then you'd want to show the default in the file, and
> var = default # default 42, range 1-100
>is maybe getting a bit cluttered.
>
>
In any case, var=default seems valuable.
>There is another issue in all this, which is that in the current scheme
>of things postgresql.conf settings override postmaster environment
>variables, for those few things for which we still accept environment
>variables --- it looks like PGPORT, PGDATESTYLE, PGCLIENTENCODING are
>the only remaining ones in CVS tip. If we put noncomment values for
>these things into postgresql.conf then the environment variables will
>be dead letters; we may as well just remove that code completely.
>
>
I'd opt for that.
>This might break things for some people.
>
>
A check for environment could remain in the code, throwing a warning
"environment is ignored", if that's really used.
How about vars overridden on the postmaster command line? Similar issue,
I believe. Naively, I'd assume that my last instruction (in this case:
changing postgresql.conf and SIGHUP) would determine processing, which
is obviously wrong if I read the docs correctly.
Regards,
Andreas