Notes on config-file-locations patch - Mailing list pgsql-hackers

There are some loose ends and inconsistencies left in the config-file-
locations feature, which I'm planning to clean up.  One problem is
that although the GUC variables allow you to find out the location
of the secondary config files, you can't verify which main config file
(postgresql.conf) the postmaster is using.  Another is that the behavior
when you write a relative path instead of an absolute path for one of
these variables is undocumented and not very consistent.  Also, I've
concluded that it's bizarre and confusing to allow the postmaster's -D
switch to reference either a directory or a config file.

What I propose to do about this is to invent an additional GUC variable
"config_file" (any suggestions for a better name?) that can be used on
the postmaster command line to select the main config file.  (Obviously
it can't be set in the config file itself, so the command line is the
only useful place to set it.)  The rules would go like this:

1. If -D appears on the command line, its argument is the "configuration
directory"; otherwise if PGDATA is set in the environment, its value is
the configuration directory; otherwise the configuration directory is
undefined.

2. If "-c config_file=foo" appears on the command line, that's where
the main config file is.  Otherwise a configuration directory must be
defined, and the main config file is ConfDir/postgresql.conf.

3. Read the config file.

4. If the "pgdata" GUC variable has been set, either in the config file
or on the command line, that's where the data directory is.  Otherwise
a configuration directory must be defined, and it also becomes the
data directory.

5. If the "hba_file" GUC variable has been set, either in the config
file or on the command line, that's where the pg_hba.conf file is.
Otherwise a configuration directory must be defined, and the HBA config
file is ConfDir/pg_hba.conf.  Similarly for the IDENT config file, and
any others we might invent in future.

6. If any of the paths obtained by these rules are relative, they are
converted to absolute relative to the postmaster's startup directory.

7. By the end of postmaster startup, the GUC variables pgdata,
config_file, hba_file, etc are filled with the correct absolute paths
for the data directory and config files, whether they were explicitly
specified or not.  These variables cannot be changed after startup,
but they can be inspected to verify which postmaster one is really
connected to.


The main difference between this and the CVS-tip behavior is that
if you want to specify the main config file directly, you write
--config_file instead of -D.  I think that's less confusing than
overloading -D with multiple meanings.

It wasn't clear to me whether we had a consensus to prevent
non-superusers from reading the values of these GUC variables.
I'm still inclined to do that, but I'll hold off until the
discussion is done.
        regards, tom lane