Re: Permanent settings
От | Magnus Hagander |
---|---|
Тема | Re: Permanent settings |
Дата | |
Msg-id | 1203458635.6983.3.camel@mha-laptop.clients.sollentuna.se обсуждение исходный текст |
Ответ на | Re: Permanent settings (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Permanent settings
(Josh Berkus <josh@agliodbs.com>)
|
Список | 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
В списке pgsql-hackers по дате отправления: