> > > 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
