From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Autogenerate some wait events code and documentation |
Date: | 2023-07-10 22:52:45 |
Message-ID: | ZKyLvXMS/D3hMFj4@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
The quotes in the second columns can be removed even with your
argument in place. That improves a bit the format.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2023-07-10 23:06:07 | Re: [PoC] Implementation of distinct in Window Aggregates |
Previous Message | Andres Freund | 2023-07-10 22:50:43 | Re: Refactoring backend fork+exec code |