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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
