Proposal for Grand Unified Configuration scheme - Mailing list pgsql-hackers

I have (almost) nothing to do for about 3 weeks, so I thought I'd get
started on some stuff for next time around.

The idea here is to unify all the various configuration settings into one
coherent scheme. This would include:

* pg_options
* pg_geqo
* postmaster.opts
* Most of the postgres and postmaster command line options
* (almost?) everything you can use SET on
* All the temporary solutions via server side environment variables

The idea would be an obvious (IMO) extension of what's done in
commands/variable.c: Every conceivable option is assigned a name similar
to an SQL identifier. With that name you could (under this proposal):

1) Do SET "foo" TO 'bar' as usual

2) Pass a default value to the backend via some generic option, say-@ foo=bar

3) Do the same via the PGOPTIONS variant from the client side

4) Provide a global default via an entry in a configuration file, say
pg_config, of the form foo=bar.

Of course the current and in general the popular options will also retain
their one letter switch in the backend.

In addition it would be nice to include some (better all) of the static
postmaster options (of the -p and -N variety) in the scheme. In that case
only (4) above will apply, of course.

What does this all accomplish you ask? Well, first of all it provides a
framework for making configuration options available via a variety of
channels in a consistent fashion. Secondly, it provides a framework for
easily adding options in the first place. No more, "should this be a
configure option?" (because it most likely should not be a configure
option :). Finally, it gives people something to do when they should be
"administering" their database server. ;)

Let me know what you think. Don't be rushed if you have other things to do
right now.


A somewhat related but more difficult and controversial project would be
to unify the options between postmaster and postgres and revise some of
the old mechanisms from the time when they were separate executables. For
example it would be nice if I could start the postmaster with the -F
option and it would look that up in the grand unified options table (see
above) and say "ah, that's a per-backend option" and pass it on to the
backend. In the above framework this wouldn't be too difficult to do, but
there are conflicting option letters between the two. Of course what
*really* ought to happen is to give up that postgres/postmaster naming
dichotomy as such, but that's another day ...

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden