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

From Andres Freund
Subject Re: Remove nonmeaningful prefixes in PgStat_* fields
Date
Msg-id 20230112180733.agmvpugp6ggorade@awork3.anarazel.de
Whole thread Raw
In response to Re: Remove nonmeaningful prefixes in PgStat_* fields  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Remove nonmeaningful prefixes in PgStat_* fields
List pgsql-hackers
Hi,

On 2023-01-12 18:12:52 +0100, Alvaro Herrera wrote:
> 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 problem with that is that the prefixes are used completely inconsistently
- and have been for a long time. And not just between the different type of
stats. Compare e.g. PgStat_TableCounts with PgStat_TableXactStatus and
PgStat_StatTabEntry. Whereas PgStat_FunctionCounts and PgStat_StatFuncEntry
both use it.  Right now there's no way to remember where to add the t_ prefix,
and where not.

Imo the reason to rename here isn't to abolish prefixes, it's to be halfway
consistent within closeby code. And the code overwhelmingly doesn't use the
prefixes.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Named Operators
Next
From: Andres Freund
Date:
Subject: Re: Minimal logical decoding on standbys