Re: [PATCH] add long options to pgbench (submission 1) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] add long options to pgbench (submission 1)
Date
Msg-id alpine.DEB.2.02.1306252026070.27845@localhost6.localdomain6
Whole thread Raw
In response to Re: [PATCH] add long options to pgbench (submission 1)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] add long options to pgbench (submission 1)
List pgsql-hackers
> I think I'd like to quibble with some of the names a bit, though.

That is a good idea, because I'm not a native English speaker and I was 
not so sure for many options.

> The patch adds --fill-factor, but I think we should spell it
> without the hyphen: --fillfactor.

Fine with me.

> I think --quiet-log should be spelled --quiet.

ISTM that --quiet usually means "not verbose on stdout", so I added log 
because this was specific to the log output, and that there may be a need 
for a --quiet option for stdout at some time.

> I think --connect for each connection is not very descriptive; maybe 
> --connection-per-transaction or something, although that's kind of long.

Yes, I think that it is too long. You have to type them!

What about '--reconnect'?

>  I think -M should be aliased to --protocol, not --query-mode.

Fine with me.

> --skip-some-update is incorrectly pluralized; if that's
> what we're going to use, it should be --skip-some-updates.

Indeed.

> Alternatively, we could use --update-large-tables-only, which might
> make the intent more clear.

Yep, but quite long.

> On another note, it doesn't look like this updates the output of
> pgbench --help, which seems important.

Indeed, it should.

Please find attached a v4 which takes into account most of your comments, 
but "very very long" option names.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pluggable compression support
Next
From: Andres Freund
Date:
Subject: Re: pluggable compression support