On 7/11/23 12:52 AM, Michael Paquier wrote:
On Mon, Jul 10, 2023 at 09:11:36AM +0200, Alvaro Herrera wrote:
I don't like this bit, because it means the .txt file is now ungreppable
as source of the enum name. Things become mysterious and people have to
track down the event name by reading the the Perl generating script.
It's annoying. I'd rather have the extra column, even if it means a
little duplicity.
Hmm. I can see your point that we'd lose the direct relationship
between the enum and string when running a single `git grep` from the
tree, still attempting to do that does not actually lead to much
information gained? Personally, I usually grep for code when looking
for consistent information across various paths in the tree. Wait
events are very different: each enum is used in a single place in the
tree making their grep search the equivalent of looking at
wait_event_names.txt anyway?
Before commit fa88928470 one could find the relationship between the enum and
the name
in wait_event.c (a simple git grep would provide it).
With commit fa88928470 in place, one could find the relationship between the
enum and the name
in wait_event_names.txt (a simple git grep would provide it).
With the proposal we are discussing here, once the build is done and so the
pgstat_wait_event.c
file is generated then we have the same "grep" capability than pre commit
fa88928470 (except that
"git grep" can't be used and one would need things like
find . -name "*.c" -exec grep -il "WAIT_EVENT_CHECKPOINTER_MAIN" {} \;)
I agree that it is less "obvious" than pre fa88928470 but still doable though.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
