On Tue, Feb 19, 2008 at 02:59:44PM -0800, Josh Berkus wrote:
> Magnus,
>
> > That's basically "include" but with a different name, no?
>
> Yes. FWIW, I seem to be lagged about 3 hours on -hackers.
>
> > Why do you need to split it in two columns, and what would go in what
> > column?
>
> Current data:
>
> postgres=# select name, category from pg_settings;
> name | category
> -------------------------+-------------------------------------------------------------------
> allow_system_table_mods | Developer Options
> archive_command | Write-Ahead Log / Settings
> archive_mode | Write-Ahead Log / Settings
> archive_timeout | Write-Ahead Log / Settings
>
> How it should be:
>
> postgres=# select name, category, subcategory from pg_settings;
> name | category | subcategory
> -------------------------+------------------------------------------------
> allow_system_table_mods | Developer Options |
> archive_command | Write-Ahead Log | Settings
> archive_mode | Write-Ahead Log | Settings
> archive_timeout | Write-Ahead Log | Settings
>
> this would then allow us to do this:
>
> select * from pg_settings_categories
> name order
> Developer Options 37
> Write-Ahead Log 11
>
> select * from pg_settings_subcategories
> name category
> allow_system_table_mods Developer Options
> archive_command Write-Ahead Log
> archive_mode Write-Ahead Log
>
> and then generate a file which looks like this:
> # == Write-Ahead Log ==
> # Settings
>
> archive_command = '/bin/rsync'
> archive_mode = 'on'
>
> # Fsync
>
> fsync = on
> wal_buffers = 8mb
>
> ... etc.
>
> This would allow the automatically generated version to be readable and
> searchable, if not quite as narrative as the present postgresql.conf.
Ok, now I see the point. But does this really work in a scenario when the
user edits the config file himself? The order will likely be broken pretty
quickly anyway in that case...
> > > 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?
>
> I meant from the SQL command line.
Oh, ok. Then I'm in agreement.
> > 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...
>
> Yeah, we've taken an Apache-like approach of including heavy comments on
> the settings in the settings file itself. Unfortunately, I think changing
> that practice at this point would alienate a bunch of users.
AFAIK, Apache doesn't document all it's parameters there. Or maybe it does
and the distributions generaelly cut it down? ;-)
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
