Re: Permanent settings - Mailing list pgsql-hackers

On Tue, 2008-02-19 at 13:31 -0800, Josh Berkus wrote:
> Magnus, All,
> 
> This is something I've been thinking about too, just because my efforts to 
> write auto-config scripts have gotten bogged down in the need to parse and 
> write .conf files in a paltform-agnostic way and preserve comments.  I 
> agree with Magnus that it's something we need to address.  Having the 
> ability to update .conf through an api other than reading & writing a file 
> one line will make developing future autotuning tools significanly easier.
> 
> I think that the idea of just appending extra lines to the bottom of the 
> file 
> in chronoligical (or random) order is so messy and hackish that it's simply 
> not worthy of consideration for the PostgreSQL project.
> 
> Instead, here's my proposal:
> 
> 1) add to the top of postgresql.conf another file switch, like this:
> 
>     # auto_config_file = 'ConfigDir/postgresql.auto.conf'
>     # if set, the auto config file will be read by the system and override the 
> settings in the rest of this postgresql.conf file, which will be ignored.
>     # to disable automated and SQL command-line-based configuration
>     # comment the above or set it to an empty string

That's basically "include" but with a different name, no?


> 2) split the "category" column in pg_settings into two columns, and add a 
> categories lookup table, so it can be sorted properly  

Why do you need to split it in two columns, and what would go in what
column?


> 3) have command line config write to postgresql.auto.conf, dumping the 
> whole of pg_settings organized with headings in categories order.

Don't get what you mean here. You mean you want a commandline tool to
generate a config file from pg_settings?


Another question completely, but related, is if it's actually the right
thing to use postgresql.conf to write documentation. The way it is now
we basically add all new config options to postgresql.conf.sample along
with a comment that is the documentation. A different approach would be
to only include the very most common settings, or possibly even only
those that initdb sets to something non-default, in
postgresql.conf.sample, and have the rest only added when they're
actually used. Documentation really belongs in the documentation, after
all...

But again, that's a different question - it's equally valid with or
without an API way for modifying the configuration.


//Magnus