Re: guc patch: Make variables fall back to default values

Joachim Wieland <joe(at)mcknight(dot)de> writes:
> On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
>> Why do you need to tell that? IMHO, once the DefineCustomFoo function
>> has been executed, it should be exactly like any other variable (other
>> than having a funny name).

> For example for the fall-back-to-default patch. I might not need to tell if
> it has been introduced by one of the DefineCustomFoo functions but for the
> "other" custom variables. Imagine that we have defined a custom variable via
> the configuration file, remove it and send SIGHUP. My understanding is that
> this variable should then be deleted from the pool of valid variables
> because it falls back to its default value and the default value of a custom
> variable is its non-existance.

Once DefineCustomFoo has been executed, you have a reset value to fall
back to. I think what you really want is to recognize variables that
are in the placeholder state, and have them go away as above.
For that you check the GUC_CUSTOM_PLACEHOLDER flag. In any case there
must never be any use of var->group for decision making; that's simply
wrong.

However, ISTM that forcing variables to go away is useless extra code.
What purpose does it serve? Not error checking, because you already
accepted the variable before. Surely you wouldn't argue that, say,
reverting to a prior setting of check_function_bodies should cause the
system to go back and validate a CREATE FUNCTION command it has already
accepted. Moreover, while you could perhaps argue that the "principle
of least surprise" cuts either way here, it seems to me there's a good
argument for not throwing away variables: you might be discarding data
the user needed. So I'd vote for just leaving them there.

regards, tom lane