Re: Row pattern recognition

Hi Ishii-san,
Thank you for the questions and corrections!

> 3. Proper Lexical Order support
> > - Respects PATTERN alternative order for ONE ROW PER MATCH
>
> RPR in WINDOW clause does not allow to specify "ONE ROW PER MATCH".
> (nor ALL ROWS PER MATCH). So I am not sure what you mean here.

You're absolutely right to point this out. I've been working without access
to the SQL:2016 standard, relying on Oracle manuals and your implementation,
which led me to incorrectly treat Window clause RPR as a variant of
MATCH_RECOGNIZE.

I now realize there are fundamental differences between R010 (RPR in window
functions) and R020 (MATCH_RECOGNIZE), and I was conflating the two. My
company is supportive of this work, and we're planning to purchase the
standard next week so I can properly understand the spec requirements.

Thank you for catching this - it's exactly the kind of spec guidance I need
as I continue learning.

> 5. Incremental MEASURES computation

> > - Aggregate values computed during matching, no rescan needed
>
> In my understanding MEASURES does not directly connect to Aggregate
> computation with rescan. Can you elaborate why implementing MEASURES
> allows to avoid recan for aggregate computation?
>

Let me clarify what I meant by "incremental aggregation" and "rescan":
In the NFA design, I'm building infrastructure for incremental aggregate
computation during pattern matching - maintaining SUM, COUNT, etc. as the
match progresses. When a match completes, if only aggregate functions are
needed, the result can be produced without accessing the original rows
again.

I used "rescan" to contrast this with what I assumed was the existing
approach: match first, then aggregate over the matched row range afterward.
However, I haven't studied your implementation carefully enough to know if
this assumption is correct.

Could you clarify how aggregates are currently computed after pattern
matching
in your implementation? This would help me understand whether the
incremental
approach actually provides a benefit, or if I'm solving a problem that
doesn't
exist.

Regarding MEASURES - I incorrectly connected it to this aggregation
discussion.
As you noted, MEASURES is a separate R020 feature, not part of R010. The
incremental aggregation infrastructure would support both cases, but they're
distinct features.

Best regards,
Henson