Re: Row pattern recognition

>
> > After that, I'll implement PATH and CLASSIFIER functions, which depend on
> > having
> > the match context available.
>
> What is PATH function? It's not in R010 or R020 as far as I know.
>

A Match Path is essentially an array consisting of the CLASSIFIER() values
of all rows
within a matched sequence, arranged in chronological order.

> > Longer-term, the goal is to get to MATCH_RECOGNIZE in the FROM clause for
> > full SQL standard compliance.
>
> What about MEASURES clause? Without it, many things in the standard
> cannot be implemented.
>

I admit that my current understanding of the full SQL standard is still
evolving. However,
looking at the current codebase, I believed that the syntax I've
implemented so far
could be addressed even before mastering every detail of the standard.
That is why I have taken a 'code-first' approach for this stage.

Of course, reaching 'FULL' compliance is undoubtedly the ultimate goal.
Given
the complexity, I believe the features should be released in several
incremental phases.
I trust that you will help define the strategic roadmap for these releases.
As I continue to
deepen my understanding of the standard, I will do my best to contribute to
the
technical roadmap as well.

> > Let me know if you have any concerns or suggestions about the approach.
>
> Here are some comments on your patches.
>
> - It is based on my v36 patches. But the latest one is v37 patch. It
> would be nice if you create patches based on the my latest patches.
>

I will rebase my work on your latest v37 patch and move forward with that
for the next version. I’ll submit the updated patch soon.

> - You are doing some optimization (like (A (B C)) gets flattened to (A
> B C) etc.) in the parse analysis phase. I think doing that kind of
> optimization should be done in the optimizer/planner. Because with
> your patch a deparsed query (as shown by pg_get_viewdef()) looks
> different from what user inputs.
>

I completely agree that those optimizations belong in the optimizer/planner
phase.
I intentionally placed them in the parse analysis phase for now to make
debugging
easier during this initial development stage. Once the logic is stabilized,
I will move
them to the planner as you suggested to ensure proper deparsing.

> - If you add files to src/backend/parser, it should be noted in
> src/backend/parser/README.
>
> - It would be noce to update typedefs patch if you add new typedefs.
>

Thank you for pointing those out. I had overlooked the README in
src/backend/parser,
and I will make sure to update it along with the typedefs patch in my next
submission.

Best regards,
Henson