On Thu, Oct 29, 2009 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
