GUC variable renaming, redux

[ just when you thought it was safe to go back in the water ]

In threads starting here and here:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00874.php
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00043.php
I believe we had reached consensus on the following points:

* log_autovacuum should be renamed log_autovacuum_min_duration to better reflect its meaning.
* stats_start_collector should go away; we should just always start the collector process.
* stats_block_level and stats_row_level should be merged into a single variable, here referred to as $merged_var, which
wouldcontrol all reports sent to the stats collector process.
 

What we lack is consensus on what the name of $merged_var should be,
and whether we should rename any related variables while at it.
I'm sending out this message in hopes of pushing that forward to
a conclusion.

First off: arguments from backwards compatibility, while not to be
disregarded, seem pretty weak here.  The variables we are thinking of
changing hardly seem likely to be set anywhere but postgresql.conf, and
we have always felt free to whack around the contents of postgresql.conf
from release to release.  Furthermore the already-agreed-to changes
would break any backwards compatibility in this area.  I think
compatibility is a reasonable argument for not indulging in wholesale
renaming of existing variables, but it should not stop us from
considering all the stats-related variables at this time.

After the agreed-on changes, "all the stats-related variables" will
actually boil down to these:
stats_command_string$merged_varstats_reset_on_server_start

There was some argument that we need to keep all these variables
similarly named; though that argument seems a bit weak seeing that
stats_command_string controls a feature which has absolutely nothing
to do with the other two variables, either from an implementation
standpoint or as to user-visible behavior.  Another problem with
stats_command_string is that it's gotten to be an extremely bad
description of the information actually made available.  (The view
it feeds, pg_stat_activity, is much more sanely named.)

Another consideration that was suggested repeatedly was that it's
good to emphasize a verb when naming one of these variables.

I found the following suggestions in the thread:
For stats_command_string:
    collect_query_string    stats_query_strings    track_activities    track_activity
For $merged_var:
    collect_event_stats    collect_stats    stats_collection    stats_count_events    stats_counters    track_events
track_stats

There wasn't any discussion of renaming stats_reset_on_server_start,
though logical consistency would seem to require this if we choose
a name not starting with stats_ for $merged_var.

Personally I would favor
    track_activities    track_counts    reset_counts_on_server_start

if we go with the "emphasize the verb" idea, or
    stats_activities    stats_counts    stats_reset_on_server_start

if we want to stick with "stats" as the key word.  Or maybe,
if we like both concepts,
    stats_track_activities    stats_track_counts    stats_reset_on_server_start

Comments?  I hope this doesn't turn into another long-drawn-out thread,
but we need to make a decision.
        regards, tom lane