Re: Parsing config files in a directory

On Thu, Oct 29, 2009 at 9:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Anyway, it seems to me a whole lot better than inventing a new thing
>> that makes "custom_variable_class" as something to append to
>> "custom_variable_classes". If you're going to insist on using "append
>> foo = 'x'" at least let it apply to the list that is actually being
>> appended to, so we don't need to keep track of singular and plural
>> forms. That's the part of your suggestion I really object to.
>
> The scheme really really has to have a "set" and an "append" operation.
> Otherwise, undesirable things happen whenever the conf file is re-read.
>
> I would envision postgresql.conf containing
>        custom_variable_classes = ''
> and then individual config files containing
>        custom_variable_classes += 'foo'
> Exact syntax isn't that important, although I confess to liking +=
> better than a keyword.
>
> Another possibility is that the reset to empty is somehow implicit
> at the start of reading the conf file.  But I'd still think it's better
> if the appending operations are visibly different from ordinary
> assignment.

I was just looking through the code for this last night and it appears
that parser generally allows either "setting = value" or "setting
value". We usually write "work_mem = 4M" and "include foo.conf" but
it looks like "work_mem 4M" and "include = foo.conf" work just as
well. If you think of custom_variable_class(es) as a declaration,
it's not so bad:

custom_variable_class 'foo'

Actually, custom_variable_classes and include already have
special-case handling in there that exists for no other GUC.

Another option would be to introduce a section syntax, something like
what M$ does. We could define a line that contains just [foo] to mean
"define foo as a custom variable class and automatically put all the
rest of the settings in this section into that namespace".

...Robert