Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
