Re: Row pattern recognition

From: Henson Choi <assam258(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-02-25 07:57:01
Message-ID: CAAAe_zC8ZfWfStbcLbutR-M_om-r9-3=jw-1=eT9e3pAFdFRzg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tatsuo,

I recently purchased the ISO/IEC 19075-5:2021 standard document
through my company, and have started cross-referencing it against
the implementation.

> nocfbot-0005: Detect zero-consumption NFA cycles

The cycle detection itself is necessary, but I found a behavioral
difference from the standard (Section 7.2.8).

When a group body is nullable (e.g. A? in (A?){2,3}), the visited
bitmap blocks re-entry to the skipped variable, so the END element
never gets a chance to produce an exit state for count < min.
The standard/Perl allows empty iterations to count toward min.

I plan to fix this by adding a compile-time flag on END elements
that indicates the group body can iterate with empty matches.
When the flag is set, nfa_advance_end() will generate the exit
state even when count < min.

> nocfbot-0006: Allow A{0} quantifier
>

After reviewing the standard, I'd like to withdraw this patch.

Section 4.14.1 explicitly requires n > 0 for the {n} quantifier.
While A{0} works correctly as an epsilon transition with the cycle
detection in place, it violates the standard.

Since we aim for standard conformance, I think we should keep the
n >= 1 restriction for {n}.

I'll include this revert in the next patch set.

Best regards,
Choi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Borisov 2026-02-25 08:21:43 Re: Improve the performance of Unicode Normalization Forms.
Previous Message Peter Eisentraut 2026-02-25 07:36:20 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row