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


Mon, 6 Mar 2000 16:59:57 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Proposal for Grand Unified Configuration scheme
Peter Eisentraut wrote:

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

    Lucky you

> The idea here is to unify all the various configuration settings into one
> coherent scheme. This would include:
>
> [...]
> 
> Let me know what you think. Don't be rushed if you have other things to do
> right now.

    Sounds good to me.


Jan from Philly

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 6 Mar 2000 22:31:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Proposal for Grand Unified Configuration scheme
Peter Eisentraut <peter_e@gmx.net> writes:
> The idea here is to unify all the various configuration settings into one
> coherent scheme.

A good goal.  Your sketch seems reasonable, but one comment:

> ... 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 fact -F is *not* a per-backend option, and certainly we dare not
change it on-the-fly via SET.  The setting is useless and even dangerous
unless all backends are behaving the same way (see pghackers archives if
you've forgotten why).  More generally, some options are reasonable to
set at any time and some aren't; your mechanism needs to deal with that.

			regards, tom lane

Tue, 07 Mar 2000 03:15:31 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Proposal for Grand Unified Configuration scheme 
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> 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

Clearly has to be done.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 7 Mar 2000 19:00:16 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Proposal for Grand Unified Configuration scheme