MIME-Version: 1.0
References: <20260209.190209.470246357440525054.ishii@postgresql.org>
 <CAAAe_zDX24SnaQFwTNVUx_vK5887mpD+rXTaedjzdfFrGROFGA@mail.gmail.com>
 <20260211.125032.1207789314761104094.ishii@postgresql.org>
 <20260212.101701.1434868071304923886.ishii@postgresql.org> <CAAAe_zDPaPiRg2gn=kRtrh+VTis5EDUeCftBK46vKsZjUHAEtA@mail.gmail.com>
In-Reply-To: <CAAAe_zDPaPiRg2gn=kRtrh+VTis5EDUeCftBK46vKsZjUHAEtA@mail.gmail.com>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Fri, 13 Feb 2026 10:14:26 +0900
Message-ID: <CAAAe_zAzOgB2KR9ACDD2o3QNP_gaCKnUd2bRGgbhcD=og50XXA@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: ssam258@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="000000000000371b5c064aaa54a5"
Archived-At: <https://www.postgresql.org/message-id/CAAAe_zAzOgB2KR9ACDD2o3QNP_gaCKnUd2bRGgbhcD%3Dog50XXA%40mail.gmail.com>
Precedence: bulk

--000000000000371b5c064aaa54a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tatsuo,

However, this raises interesting questions: should we optimize patterns
> by removing {0} quantifiers or simplifying them? And if so, how should
> we handle patterns that become empty after such optimization?
>
> For example:
> - PATTERN (A{0})          =E2=86=92 empty pattern
> - PATTERN (A{0} B{0})     =E2=86=92 empty pattern
> - PATTERN (A{0} B)        =E2=86=92 PATTERN (B) after optimization
>
> Empty patterns would result in zero-length matches, which our current
> implementation explicitly treats as invalid (see initialAdvance flag
> logic in nodeWindowAgg.c).
>
> More importantly, I recall that zero-length matches caused serious
> issues during development, which is why we added logic to explicitly
> avoid them.
>
> The reason I cannot immediately provide a concrete plan for A{0}
> support is that I need to deeply understand the semantic meaning of
> zero-length matches in the SQL standard first. Without this
> understanding, any implementation approach could be fundamentally
> flawed.
>
> Specifically, I need to investigate:
> - What zero-length matches mean semantically in RPR
> - How to handle empty patterns according to the standard
> - The correct behavior when a pattern optimizes to nothing
>
> After the current code review phase is complete, I'm also considering
> setting up an Oracle test environment to observe how it handles these
> edge cases. This could provide valuable insights into the expected
> behavior, especially for zero-length matches and empty patterns.
>

Our current implementation cannot support A{0} due to a structural
limitation.

The reduced_frame_map uses row-based representation (reduced_frame_map[pos]
=3D val),
which can only express matches consuming at least one row. It cannot
represent
zero-length matches that occur between rows without consuming any row
position.

Patterns like A{0}, A*, or A? can produce zero-length matches with no row
to mark
as RF_FRAME_HEAD and no position to register in the frame map.

We currently prevent this using the initialAdvance flag (nodeWindowAgg.c),
which skips FIN recording during initial epsilon transitions.

Supporting A{0} requires either restructuring reduced_frame_map to handle
virtual positions, or separate handling for zero-length matches. Before
choosing an approach, we need clarity on what the SQL standard expects for
zero-length match semantics (output generation, aggregate behavior, etc.).

Given this structural limitation, I'd like to ask: should we keep the
current
initialAdvance mechanism (which prevents zero-length matches) and handle
A{0}
separately?

Best regards,
Henson

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi Tatsuo,<br><div><br><=
/div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v dir=3D"ltr"><div class=3D"gmail_quote">However, this raises interesting q=
uestions: should we optimize patterns<br>by removing {0} quantifiers or sim=
plifying them? And if so, how should<br>we handle patterns that become empt=
y after such optimization?<br><br>For example:<br>- PATTERN (A{0}) =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=86=92 empty pattern<br>- PATTERN (A{0} B{0})=
 =C2=A0 =C2=A0 =E2=86=92 empty pattern<br>- PATTERN (A{0} B) =C2=A0 =C2=A0 =
=C2=A0 =C2=A0=E2=86=92 PATTERN (B) after optimization<br><br>Empty patterns=
 would result in zero-length matches, which our current<br>implementation e=
xplicitly treats as invalid (see initialAdvance flag<br>logic in nodeWindow=
Agg.c).<br><br>More importantly, I recall that zero-length matches caused s=
erious<br>issues during development, which is why we added logic to explici=
tly<br>avoid them.<br><br>The reason I cannot immediately provide a concret=
e plan for A{0}<br>support is that I need to deeply understand the semantic=
 meaning of<br>zero-length matches in the SQL standard first. Without this<=
br>understanding, any implementation approach could be fundamentally<br>fla=
wed.<br><br>Specifically, I need to investigate:<br>- What zero-length matc=
hes mean semantically in RPR<br>- How to handle empty patterns according to=
 the standard<br>- The correct behavior when a pattern optimizes to nothing=
<br><br>After the current code review phase is complete, I&#39;m also consi=
dering<br>setting up an Oracle test environment to observe how it handles t=
hese<br>edge cases. This could provide valuable insights into the expected<=
br>behavior, especially for zero-length matches and empty patterns.<br></di=
v></div></div></blockquote><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">Our current implementation cannot support A{0} due to a st=
ructural limitation.<br><br>The reduced_frame_map uses row-based representa=
tion (reduced_frame_map[pos] =3D val),<br>which can only express matches co=
nsuming at least one row. It cannot represent<br>zero-length matches that o=
ccur between rows without consuming any row position.<br><br>Patterns like =
A{0}, A*, or A? can produce zero-length matches with no row to mark<br>as R=
F_FRAME_HEAD and no position to register in the frame map.<br><br>We curren=
tly prevent this using the initialAdvance flag (nodeWindowAgg.c),<br>which =
skips FIN recording during initial epsilon transitions.<br><br>Supporting A=
{0} requires either restructuring reduced_frame_map to handle<br>virtual po=
sitions, or separate handling for zero-length matches. Before<br>choosing a=
n approach, we need clarity on what the SQL standard expects for<br>zero-le=
ngth match semantics (output generation, aggregate behavior, etc.).<br></di=
v><div class=3D"gmail_quote"><br></div>Given this structural limitation, I&=
#39;d like to ask: should we keep the current<br>initialAdvance mechanism (=
which prevents zero-length matches) and handle A{0}<br>separately?<br></div=
><div class=3D"gmail_quote"><br>Best regards,<br><div>Henson=C2=A0</div></d=
iv></div>
</div>

--000000000000371b5c064aaa54a5--