On Wed, Apr 6, 2022 at 4:12 PM Andres Freund <andres@anarazel.de> wrote:
On 2022-04-06 15:32:39 -0700, David G. Johnston wrote: > On Wednesday, April 6, 2022, Andres Freund <andres@anarazel.de> wrote: > > > I like having the SQL function paired with a matching implementation in > this scheme.
It would have gotten things closer than it was before imo. We can't just rename the SQL functions, they're obviously exposed API.
Right, I meant the naming scheme proposed was acceptable. Not that I wanted to change the SQL functions too.
I've hacked up the above, but after doing so I think I found a cleaner
approach:
I've introduced:
pgstat_reset_of_kind(PgStat_Kind kind) which works for both fixed and variable numbered stats. That allows to remove pgstat_reset_subscription_counters(), pgstat_reset_replslot_counters(), pgstat_reset_shared_counters().
pgstat_reset(PgStat_Kind kind, Oid dboid, Oid objoid), which removes the need for pgstat_reset_subscription_counter(), pgstat_reset_single_counter().
pgstat_reset_replslot() is still needed, to do the name -> index lookup.
That imo makes a lot more sense than requiring each variable-amount kind to have wrapper functions.
I can see benefits of both, or even possibly combining them. Absent being able to point to some other part of the system and saying "it is done this way there, let's do the same here" I think the details will inform the decision. The fact there is just the one outlier here suggests that this is indeed the better option.
What does "private" mean for you? They're exposed via pgstat.h not pgstat_internal.h. But not to SQL.
I was thinking specifically of the freedom to rename and not break extensions. Namely, are these truly implementation details or something that, while unlikely to be used by extensions, still constitute an exposed API? It was mainly a passing thought, I'm not looking for a crash-course in how all that works right now.