On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I think we should have an explicit include-directory directive, and the > reason I think so is that it makes it fairly easy for the user to > control the relative precedence of the manual settings (presumed to > still be kept in postgresql.conf) and the automatic settings (presumed > to be in files in the directory). Manual settings before the include > are overridable, those after are not.
I think we can actually aim higher now. We don't need nearly as many degrees of freedom as people seem to be suggesting. And in this space degrees of freedom just mean the ability to have confusing configurations that surprise users. I would suggest the following: The system always scans postgresql.conf and postgresql.conf.d in the same location. We can support include and includedir directives though I think they would be mostly unnecessary. But they would be purely for the purpose of organizing your files and adding additional locations, not replacing the standard locations. They might be useful for, for example, having a site-wide set of defaults which are loaded before the cluster-specific files. postgresql.conf settings override postgresql.conf.d settings. postgresql.conf should no longer be a place for tools to automatically edit, and ideally it should be shipped empty so anything there is an explicit manual instruction from a sysadmin and should override anything installed by a package or tool. When scanning postgresql.conf.d we should follow the Apache/Debian standard of scanning only files which match a single simple hard-coded template. I think the convention is basically the regexp ^[0-9a-zA-Z-]*.conf$. It's important that it exclude typical backup file conventions like foo~ or foo.bak and lock file conventions like .#foo. There's no need for this to be configurable and I think that would be actively harmful. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
