On Fri, Jul 07, 2023 at 01:49:24PM +0900, Michael Paquier wrote:
> Hmm. If we go down this road I would make the choice of simplicity
> and remove entirely a column, then, generating the snakecase from the
> camelcase or vice-versa (say like a $string =~ s/([a-z]+)/$1_/g;),
> even if it means having slightly incompatible strings showing to the
> users. And I'd rather minimize the number of exceptions we need to
> handle in this automation (aka no exception rules for some keywords
> like "SSL" or "WAL", etc.).
After pondering more about that, the attached patch set does exactly
that. Patch 0001 includes an update of the wait event names so as
these are more consistent with the enum elements generated. With this
change, users can apply lower() or upper() across monitoring queries
and still get the same results as before. An exception was the
message queue events, which the enums used "MQ" but the event names
used "MessageQueue", but this concerns only four lines of code in the
backend. The newly-generated enum elements match with the existing
ones, except for MQ.
Patch 0002 introduces a set of simplifications for the format of
wait_event_names.txt:
- Removal of the first column for the enums.
- Removal of the quotes for the event name. We have a single keyword
for these, so that's kind of annoying to cope with that for new
entries.
- Build of the enum elements using the event names, by applying a
rebuild as simple as that:
+ $waiteventenumname =~ s/([a-z])([A-Z])/$1_$2/g;
+ $waiteventenumname = uc($waiteventenumname);
Thoughts?
--
Michael
