> = Directory vs. single file =
>
> The main reason I've advocated a configuration file directory is to try
> and suggest a standard for tool generated config files to co-exist in.
> This particular feature doesn't *need* that. But in the long term I was
> hoping to have more tools that can write out .conf files without having
> to read and understand every existing file that's in there. It doesn't
> make that big of a difference whether this particular one lives in
> $PGDATA/postgresql.auto.conf or $PGDATA/postgresql.auto.conf. The main
> reason for the directory is to make the second such tool not further
> clutter the main $PGDATA directory.
>
> I would like to see the name of the directory be conf.d instead of
> auto.conf.d though. What's "auto" about it? Using that word just adds
> a source of confusion. The same problem exists with the file name
> itself. I was hoping for conf.d/persistent.conf here, and no use of the
> word "auto" in the code itself.
my $0.03: I agree with Greg that using the directory is a good idea, and
that his naming is an improvement.
> What I don't see a lot of value in is the config file per setting idea.
> I was hoping SET PERSISTENT put all of its changes into once place. It
> should be obvious where they came from, and that people can't edit that
> file manually without breaking the feature. To me something like
> persistent.conf gives that impression, while postgresql.auto.conf sounds
> like the output from some auto-tuning tool.
I think most users would prefer a single file. The reason
file-per-setting is being discussed is that it avoids a lot of locking
issues and code complexity.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
