Re: Remove nonmeaningful prefixes in PgStat_* fields

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Remove nonmeaningful prefixes in PgStat_* fields
Date: 2023-01-12 17:12:52
Message-ID: 20230112171252.xucefmthy5l4l2ec@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-01-12 17:14:00 Re: Named Operators
Previous Message Robert Haas 2023-01-12 17:12:15 Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation