Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

Writing out each guc in a separate file is a singularly bad idea. It's
going out of our way to confuse users about what's going on and how
they're expected to interact with the settings files and it actively
makes it harder or nearly impossible to protect against simple
failures.

1) The whole reason for conf.d directories for things like Apache or
cron or whatever is so that other software can drop in snippets
without having to parse and edit a file in place. We *do not* want
users doing that inside PGDATA.

I'm not even clear we do want this in /etc since none of our GUC
options are repeatable things like Apache virtual servers. It actually
makes *more* sense for pg_hba than it does for gucs. I think we can
assume that in the future we'll have something like it however.

2) Directories are notoriously hard to version control, most version
control systems either don't do it at all or do a weak form of version
control on directories. Even if users tried to track the changes in
these files they'll likely find it difficult to tell when two settings
were changed together or in separate changes. On the other hand if all
the settings are in a single file then even the simplest form of
version control -- backup files -- would suffice.

If we just keep a backup copy of the settings file for each change
then it would be easy for people to diff from one version to another
and see all the changes together and easy for them to restore an old
copy if the current one isn't starting up. If they're in a million
tiny files then users would have to keep a backup copy of the whole
directory and dig thorugh a recursive diff of the whole directory. Or
they would have tons of backup files for different settings at
different times and need to figure out which ones were in effect at a
given time.