Re: Remove nonmeaningful prefixes in PgStat_* fields - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Remove nonmeaningful prefixes in PgStat_* fields
Date
Msg-id 20230112171252.xucefmthy5l4l2ec@alvherre.pgsql
Whole thread Raw
In response to Remove nonmeaningful prefixes in PgStat_* fields  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: Remove nonmeaningful prefixes in PgStat_* fields
Re: Remove nonmeaningful prefixes in PgStat_* fields
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation
Next
From: Tom Lane
Date:
Subject: Re: Named Operators