On Thu, Oct 29, 2009 at 11:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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". > > That seems like a pretty darn bad idea, unless we munge the parser to > terminate the section when exiting a particular include file.
Yeah, that's what I had in mind. > Otherwise > files that don't set custom_variable_class will have surprising > interactions with those that do. I don't see any particularly great > benefit in allowing people to omit the prefix anyway --- what if you > want to set some custom and some standard variables? With the above > definition you can't do that. Honestly, I don't see much downside to that - why would you want to do such a thing? But, anyway, you could still allow an explicit namespace to be provided, and pick one (say "main") for the default namespace. Anyway, I don't feel strongly about it. The main thing is that if all the custom variable classes have to be declared in one place, then you can't really have independent config files that drop into a directory somewhere for add-on modules, because you'll still have to munge the main file to set up the custom_variable_classes. > The fact that custom_variable_classes interacts with other declarations > around it is already an ugly misfeature of the design. Let us please > not add more such interactions. It is definitely ugly, but that's partly because it's implemented as a kludge to keep the lexer simple. Declarative and section-dividing constructs are useful, which is why other config files (like Apache) have them. But do WE need them? I don't know. Honestly, we don't have that much configuration, and most of what we do have is stored in the database itself. That's a feature, and I have no desire to change it. If we could make the cluster start up without needing postgresql.conf, I'd argue for getting rid of it and keeping global GUC settings in the database just as we do for per-database, per-user, per-user-and-database, and per-function GUCs, as well as reloptions. But I think we've determined that there's really no reasonable way to make that happen. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
