On Sun, Jul 16, 2023 at 12:21:20PM -0700, Andres Freund wrote: > I think the search issue is valid, so I do think going the other way is > preferrable. I.e. use just the enum value in the .txt and generate the camel > case name from that. That allows you to search the define used in code and > find a hit in the file. > > I personally would still leave off the WAIT_EVENT prefix in the .txt, I think > most of us can remember to chop that off.
So you mean to switch a line that now looks like that: WAIT_EVENT_FOO_BAR FooBar "Waiting on Foo Bar." To that: FOO_BAR "Waiting on Foo Bar." Or even that: WAIT_EVENT_FOO_BAR "Waiting on Foo Bar." Sure, it is an improvement for any wait events that use WAIT_EVENT_ when searching them, but this adds more magic into the LWLock and Lock areas if the same conversion is applied there. Or am I right to assume that you'd mean to *not* do any of that for these two classes? These can be treated as exceptions in the script when generating the wait event names from the enum elements, of course. > I don't think we need to be particularly consistent with wait events across > major versions. They're necessarily tied to how the code works, and we've > yanked that around plenty. IMO, it depends on the code path involved. For example, I know of some code that relies on SyncRep to track backends waiting on a sync reply, and that's one sensible to keep compatible. I'd be sad if something like that breaks suddenly after a major release. -- Michael
signature.asc
Description: PGP signature
