Re: postgres --help-config

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: postgres --help-config
Date: 2003-10-10 02:37:16
Message-ID: 200310100237.h9A2bGr04578@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Where should I start on this? :-)
>
> Where should I start on all the people who are complaining now, but
> said not a word when the patch was put up for review?
>
> I'm quite annoyed at these claims that procedure wasn't followed.
> It's either selective memory or historical revisionism, and either
> way I feel it's unfair to me and to Red Hat.
>
> Let's see some specific suggestions for improvement, rather than
> bootless complaining. I'm quite prepared to agree that the patch
> could use improvement. If we can fix it before 7.4 release,
> let's do so.

OK, I have some ideas. Because you didn't document it, and couldn't get
Fernando to post a reply to Peter's questions, I assumed you didn't want
to work on it right now, and that it was in there just for Red Hat.

First, the default output should have the sorted field first. It
appears the default is to sort by context:

postgres --help-config

That should be the first printed field. However, I see you can sort by
Group, so maybe group should always be first --- that seems most
logical.

The documentation I see is the command-line help in the C file:

printf(gettext("Usage:\n %s --help-config [OPTION]... [NAME]\n\n"), progname);
printf(gettext("General Options:\n"));
printf(gettext(" NAME output information about parameters matching this name\n"));
printf(gettext(" -g GROUP output information about parameters matching this group\n"));
printf(gettext(" -l list available parameter groups\n"));
printf(gettext(" -h show this help, then exit\n"));
printf(gettext("\nOutput Options:\n"));
printf(gettext(" -G do not group by category\n"));
printf(gettext(" -m machine-friendly format: tab separated fields\n"));
printf(gettext(" -M same as -m, but header with column names is suppressed\n"));

I don't see any value to most of these parameters, and the "add them in
case they might need them" has never been our philosophy, so I don't see
why we should add them at this point. Can we just get minimal
functionality and see what people ask for --- they might ask for
something completely different from what we have spec'ed out here, and
if they do, we will have to remove existing options to meet their needs,
or maintain a bloat of options. You know I have no problems adding
options to make common tasks easier for our users, but we have no usage
cases yet to know what they want.

What would make sense is to always output sorted by Group/Name, and see
how that works for folks. I also didn't think the dashed lines were
needed --- they seemed to clutter the output:


------------------------------------------------------------
Name: preload_libraries
Context: postmaster
Group: Resource Usage / Kernel Resources
Type: string
Default value:
Description: shared libraries to preload into server

------------------------------------------------------------
Name: fsync
Context: sighup
Group: Write-Ahead Log / Settings
Type: Boolean
Default value: true
Description: force synchronization of updates to disk
The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This insures that a database cluster will recover to a consistent state after an operating system or hardware crash.
------------------------------------------------------------

vs.


Name: preload_libraries
Context: postmaster
Group: Resource Usage / Kernel Resources
Type: string
Default value:
Description: shared libraries to preload into server

Name: fsync
Context: sighup
Group: Write-Ahead Log / Settings
Type: Boolean
Default value: true
Description: force synchronization of updates to disk
The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This insures that a database cluster will recover to a consistent state after an operating system or hardware crash.

An output that uses --help-config, and takes no flags seems like the way
to go at this point. If people want specific entries, they can page
through them with less, or use a tool to extract them from the text file
--- the output is in a very clear format.

I would also indent the text description (last line) to line up with the
other data fields.

Is that enough feedback? :-)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anith Sen 2003-10-10 02:42:01 Re: Dreaming About Redesigning SQL
Previous Message Bob Badour 2003-10-10 02:35:56 Re: Dreaming About Redesigning SQL