MIME-Version: 1.0
References: <20260502.140304.670813149418899420.ishii@postgresql.org>
 <20260505.090124.365339750969814137.ishii@postgresql.org>
 <CACJufxEWL_ZnC-bs_yrg-Ys6ZUD3Ut_p1Ebj0bAcbzj67+HDAQ@mail.gmail.com>
 <20260517.190023.159085681032648582.ishii@postgresql.org>
 <CACJufxH-DZePhbdJM=8nNYceQiSbbXXLTw54iLhxiynQ+4hbBA@mail.gmail.com>
 <CAAAe_zDephfiDA_A3FN0hCymJRogEr=Rt3QoCTf4qMYDLk+xNA@mail.gmail.com>
 <CACJufxGX17thWuEOq1tM5xbRHz2HXm1asooZC3GV25MYGmYqLQ@mail.gmail.com>
 <CAAAe_zAH0MvP0TBmW3PTLeHjEpiyBz0473zJRM9pwLpseefMNw@mail.gmail.com>
In-Reply-To: 
 <CAAAe_zAH0MvP0TBmW3PTLeHjEpiyBz0473zJRM9pwLpseefMNw@mail.gmail.com>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Fri, 29 May 2026 18:41:52 +0900
Message-ID: 
 <CAAAe_zCbSU=dd-4qTL2QaBQwQ-cf51N_851a9Y5rOoz0wj0aXw@mail.gmail.com>
Subject: Re: Row pattern recognition
To: jian he <jian.universality@gmail.com>, Tatsuo Ishii <ishii@postgresql.org>
Cc: zsolt.parragi@percona.com, sjjang112233@gmail.com,
 vik@postgresfriends.org,
	er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
	peter@eisentraut.org, li.evan.chao@gmail.com, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="00000000000059ecd80652f1a8bf"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zCbSU%3Ddd-4qTL2QaBQwQ-cf51N_851a9Y5rOoz0wj0aXw%40mail.gmail.com>
Precedence: bulk

--00000000000059ecd80652f1a8bf
Content-Type: text/plain; charset="UTF-8"

Hi Jian, Tatsuo,

Jian, your review keeps paying off beyond the items themselves.  Working
through the ExecRPRProcessRow refactor you proposed -- dropping
hasLimitedFrame and fixing the "endOffsetValue != 0" Datum-vs-0
comparison -- and writing the offset-0 regression test it calls for sent
me back to the standard, where I hit a conformance reading I'd value both
of your judgments on.

The case is the single-row full window frame.  It has two spellings,
semantically identical -- both make the full window frame exactly the
current row:

    ROWS BETWEEN CURRENT ROW AND CURRENT ROW
    ROWS BETWEEN CURRENT ROW AND 0 FOLLOWING

PostgreSQL accepts both today (rpr_base tests the 0 FOLLOWING form with
PATTERN (A)).  But I'm no longer sure either is sanctioned by Subclause
6.10.2, "ROWS BETWEEN CURRENT ROW AND", which reads (paraphrasing
ISO/IEC 19075-5):

  "When performing row pattern recognition in a window, only two options
   are allowed for specifying the window frame extent:
     - ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
     - ROWS BETWEEN CURRENT ROW AND offset FOLLOWING ... [the offset]
       shall be a positive integer ..."

Two things put the single-row frame outside a literal reading, and they
hit both spellings equally:

  - CURRENT ROW as the *end* bound is not one of the two listed options;
    and

  - the offset form requires a *positive integer*, and 0 is not positive
    -- so AND 0 FOLLOWING is no better sanctioned than AND CURRENT ROW.

The two spellings therefore stand or fall together: they denote the same
one-row frame, and neither is literally among 6.10.2's options.
(README.rpr X-4 already follows the strict line -- it lists only
"UNBOUNDED FOLLOWING or n FOLLOWING".)

Either way the behavior is unambiguous: a single-row search space, so the
pattern can only ever map the current row.  That makes it a degenerate,
WHERE-like use rather than real row-pattern matching -- which one might
read as benign (so allow) or as pointless (so reject), so it doesn't
settle the question for me.

This is, in effect, a borderline, harmless standard violation: it sits
just outside 6.10.2 as written, yet is well-defined, runs cleanly, and
leaves every conforming frame unchanged.

So, concretely, the choice:

  (a) Allow it -- accept both spellings and document the degenerate
      frame as a deliberate extension; or

  (b) Forbid it -- follow 6.10.2 to the letter ("only two options" and a
      "positive integer" offset) and reject both spellings in
      transformRPR().

Which reading do you take?  Tatsuo, as co-author your call carries it;
Jian, I'd value yours too, since you were just in this code.

This isn't blocking.  The implementation accepts offset 0 today, so for
now my regression test exercises it (via the 0 FOLLOWING spelling, as
rpr_base already does); if the answer is (b), that test and the existing
one become error tests together.

Thanks,
Henson

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

<div dir=3D"ltr">Hi Jian, Tatsuo,<br><br>Jian, your review keeps paying off=
 beyond the items themselves.=C2=A0 Working<br>through the ExecRPRProcessRo=
w refactor you proposed -- dropping<br>hasLimitedFrame and fixing the &quot=
;endOffsetValue !=3D 0&quot; Datum-vs-0<br>comparison -- and writing the of=
fset-0 regression test it calls for sent<br>me back to the standard, where =
I hit a conformance reading I&#39;d value both<br>of your judgments on.<br>=
<br>The case is the single-row full window frame.=C2=A0 It has two spelling=
s,<br>semantically identical -- both make the full window frame exactly the=
<br>current row:<br><br>=C2=A0 =C2=A0 ROWS BETWEEN CURRENT ROW AND CURRENT =
ROW<br>=C2=A0 =C2=A0 ROWS BETWEEN CURRENT ROW AND 0 FOLLOWING<br><br>Postgr=
eSQL accepts both today (rpr_base tests the 0 FOLLOWING form with<br>PATTER=
N (A)).=C2=A0 But I&#39;m no longer sure either is sanctioned by Subclause<=
br>6.10.2, &quot;ROWS BETWEEN CURRENT ROW AND&quot;, which reads (paraphras=
ing<br>ISO/IEC 19075-5):<br><br>=C2=A0 &quot;When performing row pattern re=
cognition in a window, only two options<br>=C2=A0 =C2=A0are allowed for spe=
cifying the window frame extent:<br>=C2=A0 =C2=A0 =C2=A0- ROWS BETWEEN CURR=
ENT ROW AND UNBOUNDED FOLLOWING<br>=C2=A0 =C2=A0 =C2=A0- ROWS BETWEEN CURRE=
NT ROW AND offset FOLLOWING ... [the offset]<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
shall be a positive integer ...&quot;<br><br>Two things put the single-row =
frame outside a literal reading, and they<br>hit both spellings equally:<br=
><br>=C2=A0 - CURRENT ROW as the *end* bound is not one of the two listed o=
ptions;<br>=C2=A0 =C2=A0 and<br><br>=C2=A0 - the offset form requires a *po=
sitive integer*, and 0 is not positive<br>=C2=A0 =C2=A0 -- so AND 0 FOLLOWI=
NG is no better sanctioned than AND CURRENT ROW.<br><br>The two spellings t=
herefore stand or fall together: they denote the same<br>one-row frame, and=
 neither is literally among 6.10.2&#39;s options.<br>(README.rpr X-4 alread=
y follows the strict line -- it lists only<br>&quot;UNBOUNDED FOLLOWING or =
n FOLLOWING&quot;.)<br><br>Either way the behavior is unambiguous: a single=
-row search space, so the<br>pattern can only ever map the current row.=C2=
=A0 That makes it a degenerate,<br>WHERE-like use rather than real row-patt=
ern matching -- which one might<br>read as benign (so allow) or as pointles=
s (so reject), so it doesn&#39;t<br>settle the question for me.<br><br>This=
 is, in effect, a borderline, harmless standard violation: it sits<br>just =
outside 6.10.2 as written, yet is well-defined, runs cleanly, and<br>leaves=
 every conforming frame unchanged.<br><br>So, concretely, the choice:<br><b=
r>=C2=A0 (a) Allow it -- accept both spellings and document the degenerate<=
br>=C2=A0 =C2=A0 =C2=A0 frame as a deliberate extension; or<br><br>=C2=A0 (=
b) Forbid it -- follow 6.10.2 to the letter (&quot;only two options&quot; a=
nd a<br>=C2=A0 =C2=A0 =C2=A0 &quot;positive integer&quot; offset) and rejec=
t both spellings in<br>=C2=A0 =C2=A0 =C2=A0 transformRPR().<br><br>Which re=
ading do you take?=C2=A0 Tatsuo, as co-author your call carries it;<br>Jian=
, I&#39;d value yours too, since you were just in this code.<br><br>This is=
n&#39;t blocking.=C2=A0 The implementation accepts offset 0 today, so for<b=
r>now my regression test exercises it (via the 0 FOLLOWING spelling, as<br>=
rpr_base already does); if the answer is (b), that test and the existing<br=
>one become error tests together.<br><br>Thanks,<br>Henson<br></div>

--00000000000059ecd80652f1a8bf--