MIME-Version: 1.0
References: 
 <CAAAe_zBFKp7bn9YUamzNiy7s2LQ3C9VXsFLRTyVTbk+ETLfZUQ@mail.gmail.com>
 <20260305.142049.1864331791480656300.ishii@postgresql.org>
 <CAAAe_zBH=6nh6Yg9EuohthTgzHgtbhtvLYAnabg6mCHQPLLpqQ@mail.gmail.com>
 <20260306.153837.2137322608184587391.ishii@postgresql.org>
In-Reply-To: <20260306.153837.2137322608184587391.ishii@postgresql.org>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Sat, 7 Mar 2026 08:18:27 +0900
Message-ID: 
 <CAAAe_zDgbDQf=RMtGw_axaNm1d_HY-e4=0ddDy809p7kTuUwHQ@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: sjjang112233@gmail.com, vik@postgresfriends.org, er@xs4all.nl,
	jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
	peter@eisentraut.org, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fe3129064c63452b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zDgbDQf%3DRMtGw_axaNm1d_HY-e4%3D0ddDy809p7kTuUwHQ%40mail.gmail.com>
Precedence: bulk

--000000000000fe3129064c63452b
Content-Type: text/plain; charset="UTF-8"

Hi, Tatsuo

Does "a zero-length match" mean "an empty match"?
>

Yes, they refer to the same thing.  "Zero-length match" is the more
common term in general regex implementations (PCRE2, Perl, Python,
Java, etc.[1]), but the RPR standard (ISO/IEC 19075-5, Section 4.12.2)
uses "empty match" exclusively.

[1] https://www.regular-expressions.info/zerolength.html


BTW, currently we place all nfa_* functions at the bottom of
> nodeWindowAgg.c.  However nodeWindowAgg.c in master branch places "API
> exposed to window functions" at the bottom of the file. Do you think
> we should follow the way?


Yes, we should follow master's convention.  I see three options:

  (a) Reorder within nodeWindowAgg.c: move the nfa_* functions up and
      keep the "API exposed to window functions" section at the bottom,
      matching master's layout.

  (b) Separate file under src/backend/executor/, keeping it close to
      nodeWindowAgg.c while making the boundary explicit.

  (c) A dedicated src/backend/rpr/ directory modeled on
      src/backend/regex/, giving the NFA engine its own namespace.
      This could also be an opportunity to consolidate the existing
      src/backend/optimizer/plan/rpr.c into the same directory.

For now (a) is the safest change.  Longer term, (b) or (c) would make
more sense -- especially when we extend to MATCH_RECOGNIZE (R010),
where the NFA engine will need to be shared across both code paths.
Either way, the NFA engine can be exposed via a header so that R010
can share it without further restructuring.

Since the NFA algorithm is not familiar territory for most DBMS
developers, it would also be worth preserving the detailed algorithm
description posted earlier in this thread -- either as structured
comments or as a dedicated README alongside the code.

What do you think?  Should we start with (a) now and revisit the
broader restructuring approaches -- (b) or (c) -- later, or would you
prefer to discuss them first?  Either of those would also resolve the
file layout convention issue naturally, since new files would follow
proper conventions from the start.


One more thing: there are no ECPG example programs or regression tests
for RPR yet.  I'd like to propose adding them.  Shall I draft an
initial set, or would you prefer to coordinate with the ECPG
maintainers first?


Best regards,
Henson

--000000000000fe3129064c63452b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi, Tatsuo</div><div dir=3D"ltr"><br></di=
v><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Does &quot;a zero-length match&quot; mean &quot;an empty match&quot;?<br></=
blockquote><div><br></div>Yes, they refer to the same thing. =C2=A0&quot;Ze=
ro-length match&quot; is the more<br>common term in general regex implement=
ations (PCRE2, Perl, Python,<br>Java, etc.[1]), but the RPR standard (ISO/I=
EC 19075-5, Section 4.12.2)<br>uses &quot;empty match&quot; exclusively.<br=
><br>[1] <a href=3D"https://www.regular-expressions.info/zerolength.html">h=
ttps://www.regular-expressions.info/zerolength.html</a><br>=C2=A0<br><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex">
BTW, currently we place all nfa_* functions at the bottom of<br>
nodeWindowAgg.c.=C2=A0 However nodeWindowAgg.c in master branch places &quo=
t;API<br>
exposed to window functions&quot; at the bottom of the file. Do you think<b=
r>
we should follow the way?</blockquote><br>Yes, we should follow master&#39;=
s convention.=C2=A0 I see three options:<br><br>=C2=A0 (a) Reorder within n=
odeWindowAgg.c: move the nfa_* functions up and<br>=C2=A0 =C2=A0 =C2=A0 kee=
p the &quot;API exposed to window functions&quot; section at the bottom,<br=
>=C2=A0 =C2=A0 =C2=A0 matching master&#39;s layout.<br><br>=C2=A0 (b) Separ=
ate file under src/backend/executor/, keeping it close to<br>=C2=A0 =C2=A0 =
=C2=A0 nodeWindowAgg.c while making the boundary explicit.<br><br>=C2=A0 (c=
) A dedicated src/backend/rpr/ directory modeled on<br>=C2=A0 =C2=A0 =C2=A0=
 src/backend/regex/, giving the NFA engine its own namespace.<br>=C2=A0 =C2=
=A0 =C2=A0 This could also be an opportunity to consolidate the existing<br=
>=C2=A0 =C2=A0 =C2=A0 src/backend/optimizer/plan/rpr.c into the same direct=
ory.<br><br>For now (a) is the safest change.=C2=A0 Longer term, (b) or (c)=
 would make<br>more sense -- especially when we extend to MATCH_RECOGNIZE (=
R010),<br>where the NFA engine will need to be shared across both code path=
s.<br>Either way, the NFA engine can be exposed via a header so that R010<b=
r>can share it without further restructuring.<br><br>Since the NFA algorith=
m is not familiar territory for most DBMS<br>developers, it would also be w=
orth preserving the detailed algorithm<br>description posted earlier in thi=
s thread -- either as structured<br>comments or as a dedicated README along=
side the code.<br><br>What do you think?=C2=A0 Should we start with (a) now=
 and revisit the<br>broader restructuring approaches -- (b) or (c) -- later=
, or would you<br>prefer to discuss them first?=C2=A0 Either of those would=
 also resolve the<br>file layout convention issue naturally, since new file=
s would follow<br>proper conventions from the start.<br><br><br>One more th=
ing: there are no ECPG example programs or regression tests<br>for RPR yet.=
=C2=A0 I&#39;d like to propose adding them.=C2=A0 Shall I draft an<br>initi=
al set, or would you prefer to coordinate with the ECPG<br>maintainers firs=
t?<br><br><br>Best regards,<br>Henson<br></div></div>

--000000000000fe3129064c63452b--