Re: Permanent settings

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.

>
> > 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.

> 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.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco