Re: delimiter inconsistency in generate-wait_event_types.pl
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-07-29T08:08:56Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix incorrect option name in usage screen
- e5393fc2e453 18.1 landed
- 2e84996b03f5 17.7 landed
- 0fba25eb720a 19 (unreleased) landed
-
Consistently handle tab delimiters for wait event names
- 711ccce38f22 19 (unreleased) landed
Attachments
- v2-0002-Fix-incorrect-option-name-in-usage-screen.patch (application/octet-stream) patch v2-0002
- v2-0001-Consistently-handle-tab-delimiters-for-wait-event.patch (application/octet-stream) patch v2-0001
> On 29 Jul 2025, at 06:56, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > I got bitten by an inconsistency introduced about two years ago. In > the script generate-wait_event_types.pl, the intermediate line format > is parsed using a regular expression that allows multiple tab > characters between fields. However, the fields were later extracted > using split(/\t/, ...), which assumes single-tab delimiters and fails > when fields are separated by multiple tabs. This leads to a somewhat > unclear error when processing input that should otherwise be valid Nothing in the documentation for this explicitly states that multiple tab characters are supported so the alternative patch could be to remove support for \t+. That being said, such a restriction seems artificial and I prefer your approach. > Since the data was already captured via regex, using $1, $2 and $3 > instead of split() avoids the inconsistency and makes the intent > clearer. A related adjustment was made elsewhere in the script to > improve consistency. +1, using the capture groups is clearly more readable. While looking at this I noticed that the --docs option is incorrectly refered to as --sgml in the usage output, which is fixed in 0002. -- Daniel Gustafsson