Re: delimiter inconsistency in generate-wait_event_types.pl

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: delimiter inconsistency in generate-wait_event_types.pl
Date: 2025-07-29 08:08:56
Message-ID: 0BBA1BE5-EF7B-4297-8896-30EA7627B42D@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 29 Jul 2025, at 06:56, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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

Attachment Content-Type Size
v2-0002-Fix-incorrect-option-name-in-usage-screen.patch application/octet-stream 1.5 KB
v2-0001-Consistently-handle-tab-delimiters-for-wait-event.patch application/octet-stream 2.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2025-07-29 08:52:51 Re: A performance regression issue with Memoize
Previous Message Fabrice Chapuis 2025-07-29 07:48:59 pg_basebackup and pg_switch_wal()