> = 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
