On Thu, Oct 29, 2009 at 9:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
