Re: Parsing config files in a directory

On Sat, Oct 24, 2009 at 6:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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