Re: Advice regarding configuration parameters

Joe Conway <mail@joeconway.com> writes:
> I like it. I wonder if we ought to have a way to "register" valid
> classes? Maybe a new guc variable in the form of a list of valid
> classes. So something like:

There are some order-of-processing issues there, but maybe.  Another
possibility is that after a shlib has finished registering its
variables, it could look for remaining placeholders matching its prefix
and issue WARNINGs about 'em (it can't realistically ERROR, probably,
but a WARNING would surely help).  These are actually orthogonal checks
since one addresses the class part and the other the individual variable.

>> And we'd have to think a little about how to handle variable values
>> that are discovered to be erroneous when we try to assign them to the
>> variable --- probably we can just drop them, but does that make the
>> semantics weird at all?

> Maybe we can require a default value as a parameter to 
> add_guc_variable() and use that?

Well, the new GUC variable struct would include a default by definition,
and presumably that value would "bubble up" to replace any values that
are found illegal.

The sort of semantic funny I am thinking of is like this:
* postgresql.conf contains pljava::var = somegoodvalue
* ALTER DATABASE SET supplies pljava::var = somebadvalue
For builtin variables the ALTER DATABASE value would be rejected on
sight and the end result would be that the variable contains
'somegoodvalue'.  However if we don't yet know the variable at backend
startup, 'somebadvalue' will replace 'somegoodvalue' completely, and
then when the PL actually gets loaded it will get thrown away.  End
result is that the variable will have whatever its hardwired default is,
and not 'somegoodvalue' as one would wish.  Even more surprising, a
subsequent SIGHUP would make it acquire 'somegoodvalue'.

This particular case could be dealt with by forcing a rescan of
postgresql.conf after new variables are defined (I think we need only do
so if any errors are detected in assigning values), but that will not
handle everything.  We don't have any way to get back overridden values
from other sources such as the postmaster command line.

It seems likely to me that such corner cases are sufficiently bizarre to
not bother anyone, but we need to think more to make sure that there
aren't any that would bother someone.
        regards, tom lane