Re: location of the configuration files

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> Ok, if we're going this far already, tell me exactly why we have three config
> files. Why not really Unify things and fulfil the full promise of Grand
> Unified Configuration by rolling hba and ident into postgresql.conf. Is
> there a compelling reason not to do so?

Lack of backwards compatibility; unnecessary complexity. Unifying those
files would create a big headache in terms of having to unify their
syntax. And there are some basic semantic differences too. For
instance, order matters in pg_hba.conf, but not in postgresql.conf.

Another reason not to do it is that there are differences in the
security requirements of these files. postgresql.conf probably doesn't
contain anything that needs to be hidden from prying eyes, but I'd be
inclined to want to keep the other two mode 600.

---

Okay, I've been laying low all day, but here are my thoughts on the
discussion:

I do see the value in being able to (as opposed to being forced to,
please) keep hand-edited config files in a separate location from
the machine-processed data files. We have already gone some distance
in that direction over the past few releases --- there's much less in
the top $PGDATA directory than there once was. It makes sense to let
people keep hand-edited files away from what initdb will overwrite.

I would favor a setup that allows a -C *directory* (not file) to be
specified as a postmaster parameter separately from the -D directory;
then the hand-editable config files would be sought in -C not -D. In
the absence of -C the config files should be sought in -D, same as they
ever were (thus simplifying life for people like me who run many
postmasters and don't give a darn about FHS ;-)).

I don't see any great value in a separate postgresql.conf parameter for
each secondary config file; that just means clutter to me, especially
if we add more such files in future. I am also distinctly not in favor
of eliminating the PGDATA environment variable; that reads to me as
"we are going to force you to do it our way rather than the way you've
always done it, even if you like the old way".

To make the RPM packagers happy, I guess that the default -C directory
has to be settable via configure. We do not currently have a default
-D directory, and I didn't hear anyone arguing in favor of adding one.
So that leaves the following possible combinations that the postmaster
might see at startup, for which I propose the following behaviors:

1. No -C switch, no -D switch, no PGDATA found in environment: seek
postgresql.conf in the default -C directory established at configure
time. Use the 'datadir' specified therein as -D. Fail if postgresql.conf
doesn't define a datadir value.

2. No -C switch, no -D switch, PGDATA found in environment: use $PGDATA
as both -C and -D. (Minor detail: if the postgresql.conf in the $PGDATA
directory specifies a different directory as datadir, do we follow that
or raise an error? I'd be inclined to say "follow it" but maybe there
is an argument for erroring out.)

(In all the following cases, any environment PGDATA value is ignored.)

3. No -C switch, -D switch on command line: use -D value as both -C and -D,
proceed as in case 2.

4. -C switch, no -D switch on command line: seek postgresql.conf in
-C directory, use the datadir it specifies.

5. -C and -D on command line: seek postgresql.conf in -C directory,
use -D as datadir overriding what is in postgresql.conf (this is just
the usual rule that command line switches override postgresql.conf).

Cases 2 and 3 are backwards-compatible with our historical behavior,
so that anyone who likes the historical behavior will not be unhappy.
Cases 1 and 4 I think will make mlw and our packagers happy. Case 5
is just the logical conclusion for that combination.

In all cases, pg_hba.conf and pg_ident.conf would be sought in the
same directory as postgresql.conf. The other stuff in the toplevel
$PGDATA directory should stay where it is, IMHO.

I would venture that the configure-time-default for -C should be
${prefixdir}/etc if configure is not told differently, while the
packagers would probably set it to /etc/postgresql/ (ie, the
config files should live in a subdirectory that can be owned by
postgres user). I'm not wedded to that though.

Another interesting question is whether the installed-by-default
postgresql.conf should specify a datadir value, and if so what.
If initdb installs it, it can and probably should insert the actual
datadir location the user gave to initdb into the file. But should
initdb install any config files at all anymore? I'm leaning to the
thought that initdb should store default config files into $PGDATA
same as it ever did, and then it's up to the user (or package install
scripts) to move them to the desired -C directory if appropriate.
Or I suppose we could add a -C parameter to initdb to tell it where to
put 'em.

Comments?

regards, tom lane