| 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
| 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 |