Feedback-ID: ia2694551:Fastmail
Date: Thu, 12 Jan 2023 18:12:52 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Remove nonmeaningful prefixes in PgStat_* fields
Message-ID: <20230112171252.xucefmthy5l4l2ec@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9142f62a-a422-145c-bde0-b5bc498a4ada@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20230112171252.xucefmthy5l4l2ec%40alvherre.pgsql>
Precedence: bulk

On 2023-Jan-12, Drouvot, Bertrand wrote:

> Please find attached a patch to $SUBJECT.
> 
> It is a preliminary patch for [1].
> 
> The main ideas are: 1) to have consistent naming between the pg_stat_get*() functions
> and their associated counters and 2) to define the new macros in [1] the same way as it
> has been done in 8018ffbf58 (aka not using the prefixes in the macros).

I don't like this at all.  With these prefixes in place, it's much more
likely that you'll be able to grep the whole source tree and not run
into tons of false positives.  If you remove them, that tends to be not
very workable.  If we use these commits as precedent for expanding this
sort of renaming across the tree, we'll soon end up with a very
grep-unfriendly code base.

The PGSTAT_ACCUM_DBCOUNT and PG_STAT_GET_DBENTRY macros are just one
argument away from being able to generate the variable name including
the prefix, anyway.  I don't know why we had to rename everything in
order to do 8018ffbf5895, and if I had my druthers, we'd undo that.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/